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ABSTRACT 


The  United  States  Marine  Corps  is  exploring  the  concepts  of  Operational 
Maneuver  From  the  Sea  (OMFTS)  and  Ship-To-Objective  Maneuver  (STOM)  as 
methods  for  employment  of  maritime  forces  in  the  future.  At  the  same  time,  the 
Department  of  Defense  (DoD)  is  pursuing  the  acquisition  of  the  Joint  Tactical  Radio 
System  (JTRS),  a  multi-band,  multi-channel,  multi-mode  family  of  radios,  designed  to 
form  self-organizing,  self-healing  communications  networks.  The  JTRS  will  have  to 
support  Marine  forces  in  combat  at  long  distances  from  the  forces’  support  and  higher 
headquarters  units.  This  extended  range  will  require  the  use  of  relay  radios  in  order  to 
maintain  connectivity  between  the  attacking  force  and  its  support. 

This  thesis  explores  the  relay  station  bandwidth  requirements  to  support  Marine 
forces.  The  question  is  analyzed  through  the  use  of  a  discrete-event  simulation  written  in 
Java,  which  models  the  behavior  of  a  JTRS  network  in  a  STOM  scenario.  Quality  of 
service  of  the  communication  network  is  measured  by  timely  delivery  of  messages. 

The  results  of  the  simulation  indicate  that  the  JTRS  network  performance  is 
insensitive  to  relay  station  bandwidth.  Rather,  the  subordinate  headquarters  involved  in 
the  scenario  were  the  most  overloaded  nodes  in  the  network. 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


DISCLAIMER 


The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the 
official  policy  or  position  of  the  Department  of  Defense  or  the  U.S.  Government. 

The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may 
not  have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made, 
within  the  time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic 
errors,  they  cannot  be  considered  validated.  Any  application  of  these  programs  without 
additional  verification  is  at  the  risk  of  the  user. 
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EXECUTIVE  SUMMARY 


The  United  States  Marine  Corps  is  exploring  the  concepts  of  Operational 
Maneuver  From  the  Sea  (OMFTS)  and  Ship-To-Objective  Maneuver  (STOM)  as 
methods  for  employment  of  maritime  forces  in  the  future.  At  the  same  time  the 
Department  of  Defense  (DoD)  is  pursuing  the  acquisition  of  the  Joint  Tactical  Radio 
System  (JTRS),  a  multi-band,  multi-channel,  multi-mode  family  of  radios,  designed  to 
form  self-organizing,  self-healing  communications  networks.  The  JTRS  offers  great 
advances  in  communication  technologies  for  use  in  OMFTS. 

JTRS  is  currently  in  Phase  1,  Program  Definition  and  Risk  Reduction  (PDRR),  of 
the  acquisition  process.  This  phase  is  intended  to  describe  the  exact  requirements  for  a 
system  and  to  identify  low  risk  paths  to  reach  those  requirements.  The  bandwidth 
requirements  of  the  relay  suite  for  the  JTRS  have  not  yet  been  specified.  It  is  critical  to 
correctly  specify  these  requirements  because  the  JTRS  will  support  Marine  forces 
involved  in  OMFTS  and  STOM  at  long  distances  from  the  forces’  support  and  higher 
headquarters  units.  This  extended  range  will  require  the  extensive  use  of  relay  radios  in 
order  to  maintain  connectivity  between  the  attacking  force  and  its  support. 

This  thesis  explores  the  relay  station  bandwidth  requirements  to  support  Marine 
forces  in  STOM.  The  question  is  analyzed  through  the  use  of  a  discrete-event  simulation 
written  in  Java,  which  models  the  behavior  of  a  JTRS  network  in  a  STOM  scenario. 

The  simulation  developed  moves  JTRS  units  around  a  simulated  battlefield.  As 
each  JTRS  moves  through  the  simulation  it  generates  messages.  The  arrival  of  messages 
is  viewed  as  a  Poisson  process.  The  frequency  and  priority  of  these  messages  changes 
when  the  tactical  situation  of  the  JTRS  changes. 

Generated  messages  then  pass  through  the  JTRS  network  until  they  reach  their 
intended  recipient.  Messages  flow  through  the  network  following  a  few  simple  rules. 
The  two  most  important  of  these  rules  are:  a  radio  in  direct  contact  with  the  target  of  a 
message  will  always  send  it  to  the  target,  and  a  radio  not  in  contact  with  the  message’s 
target  will  send  the  message  to  a  randomly  selected  radio  with  which  it  is  in  contact 
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When  a  message  is  generated  its  priority  determines  how  long  the  system  has  to 
deliver  the  message  to  its  recipient.  A  message  that  is  not  delivered  in  less  than  that  time 
is  considered  late.  The  characteristic  of  JTRS  network  selected  for  evaluation  is  timely 
delivery  of  messages.  This  characteristic  is  measured  by  a  penalty  function  that  penalizes 
the  system  for  late  delivery  of  messages.  The  penalty  for  lateness  of  a  particular  message 
is  weighted  by  the  priority  of  that  message. 

The  scenario  used  in  the  simulation  is  an  example  of  STOM  against  two 
Objectives.  The  main  Objective  is  located  125  miles  inland  and  is  attacked  by  two 
battalions.  A  supporting  attack  of  one  battalion  is  sent  against  another  objective  that  is  30 
nautical  miles  inland.  The  regimental  headquarters  remains  aboard  amphibious  shipping, 
located  50  nautical  miles  from  shore.  The  range  across  which  the  attacking  force  must 
maintain  communication  is  up  to  175  nautical  miles. 

The  simulation  was  run  for  20  iterations  each  under  several  relay  bandwidth 
capacities.  The  results  of  the  simulation  indicate  that  the  JTRS  network  performance  is 
insensitive  to  relay  station  bandwidth.  It  is  possible  that  the  result  may  stem  from  the 
simplistic  rules  that  the  model  uses  to  route  messages  through  the  network.  Although  the 
result  is  surprising,  analysis  of  a  simplified  special  case  of  the  scenario  shows  that  the 
expected  number  of  messages  flowing  through  the  battalions’  headquarters  is 
significantly  more  than  the  expected  number  flowing  through  a  relay  station.  This 
analysis  suggests  that  the  bandwidth  of  the  battalion  headquarters  is  the  true  limiting 
parameter  in  a  JTRS  network. 
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I. 


INTRODUCTION 


As  we  enter  the  21st  Centuiy,  the  pace  of  technological  change  is  accelerating  at 
an  exceptionally  rapid  rate.  From  on-line  shopping  and  stock  trading,  to  improved 
missile  guidance  systems,  to  the  ubiquitous  cellular  phone  and  pager,  the  results  and 
possibilities  of  new  applications  of  technology  are  all  around  us.  The  ongoing 
development  of  technology  offers  opportunities  to  both  the  United  States  and  potential 
adversaries  throughout  the  world. 

The  Marine  Corps  has  applied  great  effort  and  thought  into  preparing  to  fight  and 
win  the  future  battles  of  the  nation.  Marine  Corps  Doctrinal  Publication  1  (MCDP  1), 
Warftghting  [Ref.  1]  explains  that,  although  the  nature  of  war  -  a  struggle  between  two 
independent  and  hostile  wills  -  will  not  change,  the  methods  used  to  achieve  victory  will. 
Therefore,  a  critical  part  of  our  preparation  is  considering  the  likely  effects  of  technology 
on  the  conduct  of  war. 

The  acquisition  of  the  MV-22  Osprey  tilt-rotor  aircraft  and  the  Advanced 
Amphibious  Assault  Vehicle  (AAAV)  will  give  the  Marine  operating  forces  of  the  future 
a  huge  increase  in  range,  speed  and  flexibility  in  the  execution  of  amphibious  operations. 
Extensive  thought  on  the  efficient  use  of  this  increased  capability  has  led  to  two  Marine 
Corps  Concept  Papers.  The  Operational  Maneuver  from  the  Sea  (OMFTS)  Concept 
Paper  [Ref.  2]  describes  the  tenets  and  principles  that  will  drive  maritime  power 
projection  in  the  future.  The  Ship-To-Objective  Maneuver  (STOM)  Concept  Paper  [Ref. 
3]  describes,  at  the  tactical  level  of  war,  how  the  concept  of  OMFTS  will  be  implemented 
by  the  Marine  Corps  of  the  future.  The  STOM  Concept  Paper  addresses  the  effects  of 
technology  as  follows. 

Emerging  technologies  represented  by  the  Advanced  Amphibious 
Assault  Vehicle  (AAAV),  MV-22  aircraft,  global  positioning  system 
(GPS),  and  developing  command  and  control  systems  will  radically  alter 
the  nature  of  amphibious  operations.  Landing  force  units  will  possess 
their  own  mobility  systems  -  and  have  the  ability  to  independently 
navigate  across  the  ocean  surface  to  penetrate  the  enemy’s  shoreline  at 
points  of  their  choosing...  This  combination  of  maneuver  warfare 
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philosophy  and  emerging  technologies  will  provide  the  naval  force  with 
enhanced  combat  effectiveness.  [Ref.  3] 

The  capabilities  of  current  systems  and  procedures  to  support  operations  will  be 
surpassed  by  the  demands  of  executing  OMFTS  and  STOM.  The  shortcomings  of 
existing  systems  is  not  surprising  because  current  systems  and  procedures  were  designed 
to  support  Marines  as  they  fight  today,  not  as  we  expect  them  to  fight  in  the  future.  For 
example,  current  logistic  systems  in  the  Marine  Corps  cannot  support  a  force  engaged  in 
combat  at  the  extended  distances  envisioned  by  OMFTS.  Equally  important,  current  C4I 
systems  do  not  have  the  ability  to  maintain  the  required  connectivity  with  the  assault 
force.  Once  the  rapidly  moving  force  starts  its  movement  to  the  objective,  it  will  quickly 
outstrip  the  range  of  existing  communication  systems. 

In  current-day  operations  a  Marine  force  conducting  an  amphibious  operation 
must  first  establish  itself  ashore,  build  a  logistic  support  area,  establish  terrestrial  satellite 
communication  stations,  and  then  move  to  the  objective.  The  OMFTS  concept  does  not 
allow  an  operational  pause  at  the  beachhead,  and  so  cannot  initially  rely  on  satellite 
communication  for  its  long-haul,  high  bandwidth  communication  backbone.  Only  after 
the  objective  has  been  secured  will  the  landing  force  have  the  security  and  time  to  set  up 
satellite  communications  equipment.  Until  that  time,  C4I  requirements  will  be  met  by 
organic,  mobile  C4I  assets  and  retransmission  or  relay  platforms. 

The  Marine  Corps  Combat  Development  Process  is  designed  to  ensure  that  the 
requirements  of  the  operating  forces  are  met.  In  support  of  OMFTS,  the  Requirements 
Division  of  the  Marine  Corps  Combat  Development  Command  (MCCDC)  has  developed 
a  Long-Term  C4I  Architecture.  There  are  many  uses  of  emerging  technology  in  this 
proposed  architecture,  but  no  technology  is  more  critical  than  the  Joint  Tactical  Radio 
System  (J  I  KS).  This  thesis  looks  at  the  question  of  JTRS  relay  suite  bandwidth 
sufficiency  through  the  use  of  a  discrete-event  simulation. 
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A. 


JOINT  TACTICAL  RADIO  SYSTEM 


The  JTRS  is  planned  to  be  a  multi-channel,  multi-mode  (voice,  video,  data), 
multi-band  (2-2000MHz)  family  of  radios  to  support  the  increased  bandwidth  and 
networking  requirements  of  the  warfighter  of  the  future.  The  JTRS,  as  envisioned,  will 
create  a  self-organizing,  self-healing,  network  that  will  provide  the  high  bandwidth  C4I 
backbone  for  the  Marine  Air  Ground  Task  Force  (MAGTF)  of  the  year  2015.  In  effect, 
the  JTRS  will  be  the  backbone  of  a  robust,  high  speed,  digital  Wide  Area  Network 
(WAN)  that  connects  the  Wireless  Local  Area  Networks  (WLANs)  of  subordinate  units. 
Each  WLAN  will  have  one  or  more  JTRS  radios  which  act  as  gateways  to  the  MAGTF 
WAN. 

The  Operational  Requirements  Document  (ORD)  [Ref.  4]  for  the  JTRS  has  been 
published,  and  defines  many  requirements  for  the  radio  system.  While  the  ORD  does 
define  data-rate  requirements  for  specific  band,  mode,  and  radio  configuration 
combinations,  it  does  not  specify  what  die  throughput  capabilities  of  the  communications 
relay  suite  should  be.  This  is  a  critical  question  which  needs  to  be  answered  in  order  to 
ensure  that  the  C4I  needs  of  the  Marine  Corps  are  met  in  STOM. 

The  JTRS  is  in  Phase  1  of  the  acquisition  process,  known  as  Program  Definition 
and  Risk  Reduction,  in  which  the  desired  operational  capabilities  of  the  system  are 
described.  As  shown  in  the  book  Modeling  Complex  Computer  and  Communication 
Systems  [Ref.  5],  the  cost  to  correct  design  errors  and  incorporate  design  changes  goes  up 
by  orders  of  magnitude  as  the  project  advances  toward  completion.  These  costs  increases 
are  indicated  by  the  graph  in  Figure  1 . 

It  can  be  seen,  therefore,  that  it  is  vitally  important  to  specify  the  true 
requirements  of  the  JTRS  as  accurately  as  possible  and  as  early  in  the  development 
process  as  possible.  Early  and  correct  specification  will  provide  the  Marine  Corps  with 
equipment  that  meets  its  needs,  and  will  avoid  the  large  costs  resulting  from  the  late 
addition  to  required  capabilities. 
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Figure  1.  Relative  cost  of  errors  as  related  to  phase  of  development.  After  [Ref  5] 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  analyze  the  bandwidth  required  for  the  JTRS  relay 
suite  to  support  United  States  Marine  Corps  forces  ashore  during  amphibious  operations 
in  the  year  2015.  The  nature  of  the  technologies  that  will  be  incorporated  into  the 
MAGTF  C4I  Architecture  is  largely  unknown  at  this  time.  Also  unknown  is  the  true 
current  bandwidth  requirements  of  Marine  forces  using  today’s  equipment  and  doctrine. 

This  thesis  develops  a  simulation  to  estimate  the  performance  of  the  JTRS,  given 
a  combat  scenario  and  a  set  of  parameters  describing  the  JTRS  performance.  This  tool 
will  allow  the  Marine  Corps  to  identify,  early  in  the  combat  development  process,  the 
likely  bandwidth  requirements  that  the  JTRS  must  meet.  In  particular,  the  question  of 
how  much  JTRS  bandwidth  is  required  to  support  STOM  operations  is  examined. 

In  the  absence  of  a  working  JTRS  network,  a  model  of  the  JTRS  portion  of  the 
future  MAGTF  C4I  Architecture  must  be  built.  This  model  must  be  complex  enough  to 
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model  the  expected  behavior  of  the  JTRS  and  flexible  enough  to  adapt  in  the  event  of 
changes  to  the  operating  characteristics  of  the  JTRS. 

Once  an  appropriate  model  is  developed,  measures  of  effectiveness  (MOEs)  must 
be  defined.  The  choice  of  MOEs  to  evaluate  a  system  that  does  not  exist,  and  which  is 
designed  to  support  doctrine  that  has  never  been  exercised,  is  problematic  at  best. 
Fortunately,  the  JTRS  is  designed  to  fulfill  a  function  for  which  there  is  a  current  analog 
in  digital  networks.  The  JTRS  can  thus  be  effectively  evaluated  using  the  same  MOEs 
that  are  appropriate  for  current  communications  systems  and  computer  networks. 
Although  the  methods,  capabilities  and  technologies  employed  by  the  JTRS  will  be  far 
different  from  the  currently  fielded  systems,  its  purpose  remains  the  same. 

The  characteristic  of  the  JTRS  network  selected  for  evaluation  is  the  timely 
delivery  of  messages.  This  characteristic  is  measured  by  a  weighted  penalty  function 
based  on  the  number  of  messages  that  arrive  late  to  their  destination  and  the  priority  of 
those  messages.  The  penalty  function,  then,  is  the  MOE  for  the  JTRS  network.  In  this 
situation  a  lower  MOE  score  is  better,  as  it  reflects  fewer  late  message  deliveries.  The 
penalty  function  is  more  fully  described  in  Chapter  IV. 

A  secondary  measure  of  effectiveness  for  the  JTRS  is  the  number  of  relay  sites 
required  to  support  the  landing  force.  The  minimum  number  of  relay  sites  to  support  an 
operation  is  heavily  dependent  on  the  scenario  examined.  In  the  simplest  case  of  one 
headquarters  and  one  maneuver  element,  the  number  of  relay  sites  required  is  simply  the 
number  required  to  span  the  maximum  distance  separation  between  the  headquarters  and 
its  subordinate  unit.  In  more  complicated  scenarios,  those  with  multiple  maneuver 
elements,  the  number  of  relay  sites  will  go  up,  depending  on  the  scenario  examined. 
However,  regardless  of  the  topology  of  the  network,  this  MOE  is  only  a  function  of  the 
range  of  the  communication  systems  being  used.  Of  interest  however  is  the  behavior  of 
the  network  when  additional  relay  sites  are  placed  in  parallel  along  the  communications 
path.  The  effects  of  additional  parallel  relay  sites  can  be  examined  using  the  Penalty 
Function. 
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C.  METHODOLOGY 


This  thesis  will  model  the  MAGTF  C4I  system  using  a  discrete-event  simulation 
and  will  employ  the  software  package  Simkit  to  implement  the  model.  Analysis  of  the 
system  simulation  will  be  conducted  using  the  statistics  gathering  features  of  Simkit. 
JTRS  system  parameters  and  scenario  parameters  will  be  varied  to  gain  insight  into  the 
critical  threshold  requirements  of  the  JTRS. 

D.  THESIS  ORGANIZATION 

The  remainder  of  this  thesis  is  organized  as  follows.  Chapter  II  describes  the 
background  of  the  doctrinal  and  technical  changes  leading  to  this  thesis.  Chapter  HI 
describes  the  discrete-event  simulation  approach  in  general  and  Simkit  in  particular. 
Chapter  IV  describes  the  model  developed  for  this  thesis,  it’s  MOEs,  and  the  scenario 
used  to  demonstrate  the  model.  Chapter  V  contains  the  scenario  results.  Chapter  VI 
contains  conclusions  and  a  recommendation  and  identifies  areas  for  further  research  and 
improvement  of  the  model. 
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II.  BACKGROUND 


An  appreciation  of  the  doctrine  supporting  and  directing  Marine  Corps  forces  in 
the  year  2015  aids  in  understanding  the  nature  of  problem  addressed  in  this  thesis.  Also 
important  is  an  understanding  of  the  likely  employment  of  the  JTRS  in  support  of  this 
doctrine  as  envisioned  in  the  Marine  Corps  Long-Term  C4I  Architecture. 

There  are  unique  challenges  in  modeling  a  communication  system  that  has  not  yet 
been  completely  specified.  This  modeling  effort  is  made  doubly  hard  by  the  fact  that  the 
Marine  Corps  cannot  even  quantify  current  bandwidth  requirements,  due  to  a  paucity  of 
communications  traffic  data.  Therefore,  it  is  critical  to  understand  the  fundamental 
concepts  of  OMFTS  and  STOM,  which  are  discussed  next.  Following  that,  the  JTRS  and 
the  Marine  Corps  Long-Term  C4I  Architecture  are  addressed.  The  chapter  concludes 
with  a  discussion  of  the  lack  of  communications  data,  and  the  steps  being  taken  to 
mitigate  the  problem. 

A.  OPERATIONAL  MANEUVER  FROM  THE  SEA 

The  information  in  this  section  is  drawn  entirely  from  the  Marine  Corps  Concept 
Paper,  Operational  Maneuver  From  The  Sea  [Ref.  2],  Although  almost  four  years  old, 
the  OMFTS  Concept  Paper  remains  the  key  document  used  to  describe  how  the  Marine 
Corps  will  apply  maneuver  warfare  to  amphibious  operations  and  take  advantage  of 
technological  changes  occurring  now  and  in  the  future. 

The  OMFTS  Concept  Paper  is  subtitled  “A  Concept  for  the  Projection  of  Naval 
Power  Ashore”  and  it  makes  a  strong  case  for  America’s  need  for  a  “...credible, 
forwardly  deployable  power  projection  capability.”  [Ref.  2]  This  forwardly  deployable 
force  must  have  a  “. . .  forcible  entry  capability  that  is  independent  of  forward  staging 
bases,  friendly  borders,  overflight  rights,  and  other  politically  dependent  support.”  These 
needs  point  to  U.S.  naval  forces  (U.S.  Navy  and  U.S.  Marine  Corps)  with  the  strength  to 
deal  with  any  hostile  action,  be  that  action  a  natural  disaster  or  enemy  military  activity, 
and  the  flexibility  to  do  so  at  any  time  in  any  location. 
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The  OMFTS  Concept  Paper  describes  the  nature  of  the  threats  the  Marine  Corps 
expects  to  meet  in  the  2 1st  Century,  the  response  to  those  threats  and  the  path  which  must 
followed  to  be  able  to  have  the  proper  response  to  future  threats.  The  threats  of  the  future 
cannot  be  known,  but  the  trends  of  today  can  be  projected  forward  to  give  hints  about  the 
enemies  the  United  States  and  her  Marine  Corps  will  face.  The  OMFTS  Concept  Paper 
predicts  three  general  threats  to  American  security. 

The  first  of  these  threats  is  the  rise  in  non-state  fighters,  those  fighting  for  their 
religion,  tribe,  or  ethnic  group,  but  not  associated  with  a  particular  nation  state.  While 
the  world  has  had  such  fighters  throughout  histoiy,  the  OMFTS  Concept  Paper  predicts 
an  increase  in  their  numbers  and  activities  in  the  evolving  political  scene. 

The  second  general  area  of  threat  is  the  developing  regional  powers.  These 
powers  are  defined  as  nations  with  strong  militaries  that  can  dominate  their  neighboring 
states  politically,  militarily,  or  economically.  OMFTS  makes  the  point  that  not  all  of 
these  regional  powers  will  be  threats  to  the  security  of  the  United  States.  Some  of  these 
regional  powers  will  be  hostile  and  some  will  be  friendly,  but  all  will  have  the  ability  to 
threaten  the  security  of  the  United  States. 

These  two  threats  can  be  seen  as  a  result  of  the  end  of  the  cold  war  and  the  fall  of 
the  Soviet  Union.  The  collapse  of  the  Soviet  Union  left  the  United  States  as  the  only 
superpower  in  the  world.  The  third  threat,  and  the  most  unknown,  is  the  next 
superpower.  History  shows  that  a  single  dominant  power  remains  dominant  only  for  a 
limited  time;  eventually  some  new  power  arises  to  threaten  the  dominance.  Accepting 
that  America  will  have  a  rival  superpower  some  time  in  the  future  does  not  tell  us 
anything  about  that  superpower.  Such  a  superpower  could  be  a  current  state,  a  new  state 
we  are  unfamiliar  with,  or  an  alliance  of  states.  The  important  assumption  is  that  there 
will  eventually  be  a  superpower  threat  to  American  interests  and  the  Marine  Corps  must 
be  ready  to  meet  that  threat. 

In  order  to  meet  these  threats,  OMFTS  has  six  defining  characteristics.  These  are 
that  Operational  Maneuver  From  The  Sea: 

1 .  Focuses  on  an  operational  objective. 

2.  Uses  the  sea  as  maneuver  space. 
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3.  Generates  overwhelming  tempo  and  momentum. 

4.  Pits  strength  against  weakness 

5.  Emphasizes  intelligence,  deceptions,  and  flexibility. 

6.  Integrates  all  organic,  joint,  and  combined  assets.  [Ref.2] 

Figure  2,  drawn  from  an  OMFTS  brief  given  by  MCCDC  [Ref.  6],  depicts  a 
notional  example  of  OMFTS.  Notice  that  this  example  focuses  on  an  operational 
objective  and  uses  the  sea  as  maneuver  space.  Also  note  the  huge  distances  to  be  crossed 
and  communicated  over. 

The  concepts  dealt  with  in  OMFTS  define  the  way  ahead  for  the  Marine  Corps. 
In  defining  required  capabilities,  the  OMFTS  Concept  Paper  has  this  to  say  about 
Command  and  Control: 

The  command  and  control  system  best  suited  to  OMFTS  will  be  very 
different  from  those  developed  to  deal  with  previous  approaches  to  amphibious 
warfare.  Techniques  previously  employed  to  compensate  for  the  inability  of  fire 
support  units  to  see  the  battlefield  will  give  way  to  techniques  that  exploit  the  fact 
that  combatant  units  will  be  better  informed  than  ever  before.  Communications 
systems  designed  to  provide  a  few  headquarters  with  an  overall  view  of  the 
situation  will  have  to  be  replaced  by  those  that  provide  units  with  control  over  the 
information  they  need.  [Ref.  2] 

The  STOM  Concept  Paper  calls  the  OMFTS  Concept  Paper  the  “capstone  Marine 
Corps  Concept  Paper.”  [Ref.  3]  As  the  capstone,  the  OMFTS  Concept  Paper  serves  as 
the  master  plan  for  how  the  Marine  Corps  approaches  the  challenges  of  the  future.  By 
necessity  the  OMFTS  Concept  Paper  is  broad  and  somewhat  vague,  dealing  with  topics 
as  seemingly  unconnected  as  the  nature  of  the  threat  in  the  21st  century,  training  and 
education,  and  command  and  control.  The  job  of  filling  in  the  details  is  left  to  other 
Marine  Corps  Concept  Papers. 


OMIFTS::  THE  VISION 


Figure  2.  An  illustration  of  OMFTS.  From  Ref.  [6]. 


B.  SHIP-TO-OBJECTIVE  MANEUVER 

The  background  section  of  the  STOM  Concept  Paper  itself  provides  the  best 
possible  description  of  its  purpose. 

Emerging  technologies  represented  by  the  Advanced  Amphibious 
Assault  Vehicle,  MV-22  aircraft,  global  positioning  system  (GPS),  and 
developing  command  and  control  systems  will  radically  alter  the  nature  of 
amphibious  operations.  Landing  forces  will  have  their  own  mobility 
systems  -  and  have  the  ability  to  independently  navigate  across  the  ocean 
surface  to  penetrate  the  enemy’s  shoreline  at  points  of  their 
choosing. . .  .These  new  capabilities  will  enable  tactical  commanders  to 
make  decisions  as  the  situation  develops  to  exploit  enemy  weaknesses  and 
maintain  the  momentum  of  the  attack  from  the  ship  to  the  objective. . .  .This 
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paper,  Ship-To-Objective  Maneuver,  describes  this  new  tactical  concept 

for  conducting  amphibious  forcible  entry.  [Ref.  3] 

STOM  seeks  to  apply  the  six  key  elements  of  OMFTS  to  the  tactical  execution  of 
amphibious  operations.  STOM  has  distilled  its  own  purpose  as  follows. 

1.  Control  tempo/overwhelm  adversary. 

2.  Combined  arms  maneuver  from  over  the  horizon  (OTH). 

3 .  Dilute  the  enemy  by  enlarging  battlespace. 

4.  Control  vital  area  by  fighting  outside  it. 

5.  Maneuver  to  cause  and  exploitable  reaction.  [Ref.  3] 

STOM  is  best  described  graphically.  The  remainder  of  this  section  will  use 
various  figures,  along  with  discussion  of  STOM  terms  and  concepts  drawn  from  the 
STOM  Concept  Paper. 

Figure  3,  drawn  from  the  MCCDC  Concepts  Division’s  Marine  Corps 
Warfighting  Concepts  for  the  21st  Century  Brief  [Ref.  7]  shows  the  difference  between 
today’s  reality  and  tomorrows  ideal.  The  Amphibious  Task  Force  (ATF)  consisting  of  at 
least  U.S.  Navy  and  U.S.  Marine  forces,  and  also  possibly  joint  and  multinational  forces, 
launches  an  operation  against  a  threat  located  at  the  objective  (OBJ).  Today,  all  Marine 
forces  converge  and  establish  a  Force  Beach  Head  Line  (FBHL)  in  order  to  allow 
supplies  and  follow-on  forces  to  be  brought  into  the  Beach  Support  Area  (BSA).  Only 
after  this  buildup  and  consolidation  can  the  force  move  forward  to  seize  the  objective. 
This  buildup  will  be  avoided  in  the  future.  Under  concept  of  STOM,  maneuver  forces 
will  move  directly  to  their  objectives,  following  the  path  of  least  resistance,  in  order  to 
maintain  their  combat  power  for  the  decisive  action  at  the  objective 

Figure  4  shows  the  mobility  assets  that  will  make  STOM  possible.  The  entire 
concept  of  STOM  relies  on  these  three  vehicles,  the  AAAV,  the  MV-22  ,  and  the  Landing 
Craft  Air  Cushioned  (LCAC),  collectively  referred  to  throughout  the  Marine  Corps  as 
“the  triad.”  These  vehicles  will  increase  the  striking  range  of  the  MAGTF  from  where  it 
is  today  to  the  distances  shown  in  this  figure.  Note  that  the  objective  could  be  an 
additional  100-200  Nautical  Miles  (NM)  from  the  shore. 
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Figure  3.  Amphibious  operations  today  vs.  tomorrow.  From  [Ref.  7J. 


Figure  4.  Depiction  of  a  STOM  operation.  From  [Ref.  6]. 
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The  STOM  Concept  Paper  sets  forth  the  lexicon  for  future  amphibious  operations 
and  attempts  to  add  valid  tactics  to  the  Marine  Corps  leader’s  set  of  skills.  The  ideas  of 
STOM  are  supported  by  the  triad  of  AAAV,  MV-22,  and  LCAC.  In  order  for  these 
concepts  to  work,  the  command  and  control  systems  of  the  future  must  evolve  to  support 
STOM.  The  concept  paper  recognizes  this  and  says  the  following. 

Command  and  control  provide  the  mechanism  by  which  a 
commander  recognizes  what  needs  to  be  done  and  communicates  those 
actions  required  to  ensure  mission  accomplishment. ..  .Command  and 
control  systems  must  provide  landing  force  commanders  at  all  echelons  a 
common  operational  picture  and  the  connectivity  to  monitor  execution  and 
to  influence  events  when  necessary. 

[Ref.  3] 

The  STOM  Concept  Paper  indicates  that  there  is  an  understanding  among  the 
Marine  Corps  leadership  that  the  mobility  triad  alone  is  not  enough  to  enable  the  Marine 
Corps  to  execute  OMFTS  and  STOM.  It  is  clear  that  that  today’s  C4I  system  must 
evolve  into  a  more  flexible  and  capable  system  to  support  the  types  of  operations  we  plan 
to  conduct. 

C.  JOINT  TACTICAL  RADIO  SYSTEM 

The  majority  of  the  information  contained  in  this  section  comes  from  the  JTRS 
JPO  website  [Ref.  8].  Because  this  is  an  active  acquisition  program,  JTRS  may  be  forced 
to  change  to  adapt  to  developing  technology  or  because  of  the  limitations  of  technology. 
Despite  this  uncertainty,  the  basic  facts  presented  here  have  remained  unchanged  since 
the  Mission  Needs  Statement  (MNS)  [Ref.  9]  for  JTRS  was  written  in  1997. 

JTRS  will  be  an  open  architecture,  software  programmable  system.  This  will 
allow  future  upgrades  as  the  state  of  the  art  advances.  The  fact  that  it  is  software 
programmable  will  speed  the  upgrade  process  when  it  becomes  necessary.  This  is  a  step 
beyond  the  traditional  hardware-based  digital  radio  of  the  current  force.  [Ref.  9] 
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JTRS  will  provide  both  line-of-sight  and  beyond-line-of-sight  capabilities  and 
will  operate  from  2-2000  MHz.  JTRS  will  transmit  voice,  video  and  data.  The 
waveforms  required  to  meet  this  requirement  have  not  been  chosen,  but  this  wide  range 
of  capabilities  will  put  JTRS  far  ahead  of  any  existing  radio  system. 

JTRS  will  be  a  family  of  radios.  This  family  will  provide  communications  for 
ground  units,  ships,  and  aircraft.  The  different  domains  will  require  different  radios  to 
perform  their  missions,  but  by  relying  on  the  common  open  architecture,  all  members  of 
the  family  will  be  able  to  share  waveform  software  and  will  remain  interoperable.  [Ref. 
8] 

By  providing  voice,  video,  and  data  transmission  from  2-2000  MHz  across  the 
full  spectrum  of  users  on  an  upgradeable  platform,  JTRS  can  claim  to  be  the  “DoD  radio 
of  the  future.”  [Ref.  8] 


D.  USMC  C4I  LONG-TERM  ARCHITECTURE  IN  SUPPORT  OF  STOM 

The  USMC  C4I  Long-Term  Architecture  is  the  umbrella  term  for  the  efforts  that 
have  gone  into  describing  the  architecture  that  will  support  Marine  forces  conducting 
OMFTS  and  STOM.  It  is  in  fact  not  the  next  generation  architecture,  but  rather  the 
architecture-after-next. 

The  paper,  “Overview  of  the  Proposed  2010  Command,  Control,  Communication, 
Computers,  Intelligence  and  Reconnaissance  (C4ISR)  Architecture  for  the  Marine  Corps” 
[Ref.  10],  produced  by  the  C4ISR  Architecture  Branch  of  the  Requirements  Division  of 
MCCDC,  provides  the  most  accessible  description  of  the  probable  attributes  of  the 
architecture-after-next.  The  paper’s  abstract  in  its  entirety  is  as  follows. 

This  paper  briefly  outlines  the  draft  Marine  Corps  communications 
architecture  for  the  year  201 0.  This  architecture  is  characterized  by 
numerous  low-power  wireless  local  area  networks  tied  together  by  a  self¬ 
organizing  backbone  of  Joint  Tactical  Radio  Systems  radios.  [Ref.  10] 
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This  architecture  is  seen  in  Figure  5.  Note  that  JTRS  wide  area  network  (W AN) 
is  made  up  of  JTRS  nodes  linking  the  wireless  local  area  networks  (WLANs)  of 
subordinate  units.  Figure  5  also  depicts  the  use  of  relays  to  maintain  the  network.  These 
relays  may  be  on  the  ground  or  airborne. 
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Figure  5.  Notional  MAGTF  C4I  architecture  in  2010.  From  [Ref.  10]. 


E.  DATA  USED  IN  THIS  THESIS 

The  Marine  Corps  has  not  accurately  quantified  the  bandwidth  it  requires  to 
conduct  combat  operations  today,  let  alone  in  fifteen  years.  Extensive  work  has  been 
done  by  Raytheon  Systems  Company  in  modeling  the  USMC  Regiment  and  Below 
Architecture,  specifically  looking  at  the  Near  Term  C4I  Architecture  of  the  Marine 
Corps.  According  to  a  MCCDC  brief  to  the  JTRS  Joint  Program  Officer  (IPO)  [Ref.  1 1]: 
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1  Detailed  C2  traffic  load  information  does  not  exist. 

2.  Digitization  and  doctrine  are  still  relatively  new. 

3.  No  collection  of  detailed  traffic  during  actual  deployment  of  systems  has 
occurred. 

4.  Load  Method  used  by  Raytheon  System  is  based  on  ‘Best  Engineering 
Judgment.’ 

The  result  of  this  Raytheon  simulation  study,  the  USMC  Communications 
Architecture  Study:  Final  Report  [Ref.  12]  details  the  attempts  made  by  the  analysts  to 
determine  communication  loads  for  the  simulation.  The  study  used  the  Marine  Corps 
Message  Event  Occurrence  (MEO)  database.  The  MEO  lists  Marine  Corps  Operating 
Facilities  (OPFAC),  which  can  be  described  as  the  command  and  control  nodes  of  the 
force.  For  each  OPFAC  the  MEO  database  contains  a  listing  of  the  type  of  messages  that 
particular  OPFAC  might  send  to  any  other  OPFAC. 

The  MEO  database  does  not  describe  the  frequency  of  any  message  type.  In  the 
case  of  the  Raytheon  study,  the  analysts  used  their  best  judgment  to  determine  the 
estimated  number  of  times  a  particular  message  might  occur  in  a  given  time  period  of  the 
simulation.  Similarly,  the  voice  load  of  the  network  was  simulated  by  a  message 
generator  that  produced  messages  which  have  an  exponentially  distribute  length,  with  a 
mean  length  of  eight  seconds.  The  frequency  of  voice  transmissions  was  determined  by 
setting  voice  load  as  a  percentage  of  available  bandwidth,  varying  by  the  phase  of  the 
simulation.  While  these  are  all  defendable  and  required  assumptions  of  the  model,  they 
point  to  the  lack  of  precision  in  the  description  of  the  Marine  Corps’  bandwidth  usage. 

It  will  be  very  difficult  for  the  Marine  Corps  to  take  the  steps  to  predict  future 
bandwidth  utilization  until  current  utilization  is  identified.  New  C4I  systems  are  planned 
to  add  capability  to  the  MAGTF.  Similarly,  some  current  systems  will  be  phased  out  of 
service  as  new  equipment  is  fielded.  In  order  to  predict  future  bandwidth  requirements  it 
is  necessary  to  first  identify  current  requirements  and  second  to  adjust  that  requirement 
by  the  anticipated  changes  to  bandwidth  requirements  caused  by  the  addition  and  deletion 
of  specific  C4I  systems. 
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The  traffic  load  question  is  a  large  challenge,  and  on  the  surface  it  may  appear 
that  the  desired  result  cannot  be  attained.  Fortunately,  the  Marine  Corps  is  committed  to 
improving  our  understanding  of  bandwidth  requirements  for  the  force  of  the  future,  and  is 
continuing  to  develop  the  tools  and  metrics  to  quantify  those  requirements.  MCCDC  is 
funding  Raytheon  to  further  develop  the  Regimental  Landing  Team  Mid-Level  Fidelity 
Simulation  Scenario.  The  results  of  this  simulation,  along  with  expected  updates  as 
architecture  changes  over  the  course  of  time,  will  provide  a  solid  measure  of  the 
bandwidth  requirements  of  USMC  forces  in  a  broad  range  of  operations. 

This  thesis  will  analyze  the  relay  problem  by  developing  a  discrete-event 
simulation  model  that  incorporates  the  key  distance,  bandwidth,  and  C4I  load  issues 
involved  in  STOM.  The  approach  taken  in  the  absence  of  empirical  traffic  size  and 
frequency  data  is  to  provide  notional  message  data  for  this  thesis.  Message  size  and 
inter-arrival  times  are  treated  as  random  variables  and  are  assigned  distributions.  As  the 
Marine  Corps  continues  to  explore  the  area  of  traffic  analysis,  data  will  become  available. 
Those  data,  based  on  the  Regimental  Landing  Team  Mid-Level  Fidelity  Simulation 
Scenario,  will  further  improve  the  validity  of  the  model  output. 
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III.  DISCRETE-EVENT  SIMULATION  AND  SIMKIT 


This  chapter  opens  with  a  discussion  of  the  reasons  for  selecting  a  discrete-event 
simulation  as  the  method  to  be  used  to  analyze  the  JTRS  radio  network  in  support  of 
Marine  Forces  of  the  future.  The  chapter  continues  with  an  overview  of  discrete-event 
simulations,  in  order  to  aid  in  the  reader’s  understanding  of  Chapter  IV’ s  description  of 
the  model.  The  chapter  concludes  with  an  introduction  to  Simkit,  the  program  used  to 
formulate  the  simulation. 

A.  DISCRETE-EVENT  SIMULATION 

Figure  6,  drawn  from  Simulation  Modeling  &  Analysis  [Ref.  13],  broadly  depicts 
the  methods  that  can  be  used  to  study  a  system.  Each  descending  tier,  reading  from  left 
to  right,  adds  to  the  degree  of  abstraction.  In  the  case  of  the  JTRS,  the  lack  of  an  existing 
system  precludes  experimentation  with  the  actual  system.  The  mathematical  and 
analytical  training  of  the  operations  researcher  lead  to  a  greater  preference  for,  and  ability 
with,  building  a  mathematical  model  rather  than  constructing  a  physical  model.  Finally,  a 
complex  stochastic  system,  such  as  a  military  communication  network,  does  not  lend 
itself  to  analytical  solution,  thus  leaving  simulation  as  the  preferred  method  to  study  the 
problem.  This  thesis  will  therefore  use  the  discrete-event  approach  to  simulation. 

Simulation  Modeling  &  Analysis  [Ref.  13]  describes  the  discrete-event  simulation 
method  as  follows.  “Discrete-event  simulation  concerns  the  modeling  of  a  system  as  it 
evolves  over  time  by  a  representation  in  which  the  state  variables  change  instantaneously 
at  separate  points  in  time.”  [Ref.  13]  The  status  of  the  system  is  tracked  over  the  course 
of  the  simulation  by  the  state  variables  of  the  system,  an  event  list,  and  use  of  a 
simulation  clock.  It  is  possible  to  advance  through  the  simulation  either  by  time-step  of 
by  event-step.  This  thesis  will  use  the  event-step  method  of  discrete-event  simulation. 

State  variables  are  those  elements  of  the  model  of  the  system  that  change  over 
time  and  describe  the  functioning,  performance  or  abilities  of  the  system.  The  values  of 
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the  state  variables  at  any  given  time  completely  describe  the  system  being  simulated. 
That  is  to  say  that  each  element  of  the  set  consisting  of  all  possible  combinations  of 
values  of  the  state  variables  describes  a  particular  state  of  the  system  as  a  whole.  From 
this  it  follows  that  the  only  way  to  change  the  system  is  to  change  one  or  more  of  the 
state  variables,  thus  transitioning  to  a  new  element  of  the  set  of  possible  values  and  so 
describing  a  new  state  of  the  system.  State  variables  make  instantaneous  changes  at 
discrete  points  in  time,  remaining  fixed  between  these  instantaneous  changes  rather  than 
changing  continuously. 


Figure  6.  Ways  to  study  a  system.  After  [Ref.  13] 

The  event  list  is  simply  a  time-sequenced  list  of  all  future  events  scheduled  for  the 
system  being  simulated.  Each  of  these  events  on  the  event  list  may  schedule  other  future 
events  or  may  change  the  state  variables  of  the  system,  or  both. 

The  simulation  clock  controls  the  execution  of  the  events  stored  on  the  event  list. 
The  clock  moves  in  discrete  blocks  of  time  from  the  first  event  on  the  event  list  to  the 
next.  The  simulation  performs  no  work  between  events  scheduled  on  the  event  list. 
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instead  the  clock  “jumps”  from  the  current  time  to  the  time  of  the  next  event.  When  the 
simulation  clock  jumps  to  the  next  time  for  which  an  event  is  scheduled  the  events 
scheduled  occur,  have  their  effect  on  the  system,  and  are  then  removed  from  the  event 
list.  The  simulation  clock  then  moves  to  the  next  time  for  which  events  are  scheduled. 

The  first  step  in  simulating  a  system  with  the  discrete-event  approach  is  to  define 
the  state  variables  needed  to  describe  the  system  to  be  simulated.  Once  the  state  variables 
have  been  defined,  the  next  step  is  to  determine  all  of  the  events  that  cause  the  state 
variables  to  change.  This  process  requires  careful  analysis  of  the  system  at  its  most  basic 
level.  As  a  simple  example,  imagine  simulating  a  queue  of  people.  The  single  state 
variable  that  describes  a  queue  is  the  number  of  people  in  the  queue.  There  are  only  two 
events  that  can  change  the  state  variable:  another  person  joins  the  queue,  or  a  member  of 
the  queue  leaves.  At  the  most  basic  level  then,  a  queue  can  be  described  by  a  single  non¬ 
negative  number  which  can  be  change  by  only  two  events. 

One  very  useful  technique  to  support  this  decomposition  and  to  aid  in  the 
description  of  discrete-event  simulations  is  the  use  of  an  Event  Graph.  Event  Graphs 
were  introduced  by  Schruben  in  Simulation  Modeling  with  Event  Graphs  [Ref.  14]  and 
further  discussed  by  Buss  in  Introduction  to  Event  Graphs  [Ref.  15],  An  Event  Graph  is 
a  directed  graph  consisting  of  nodes  and  edges.  The  nodes  of  the  Event  Graph  indicate 
the  events  of  the  discrete-event  simulation  and  the  edges  are  used  to  schedule  future 
events.  The  edges  of  the  Event  Graph  may  include  a  scheduled  time  delay  and  can  also 
have  a  Boolean  condition  controlling  the  scheduling  of  the  future  event. 

Figure  7  captures  the  essence  of  the  event  graph.  When  event  A  occurs,  event  B 
is  scheduled  with  a  time  delay  of  today  from  the  current  time,  if  the  Boolean  condition  i  is 
true.  In  the  case  where  the  Boolean  condition  is  false  the  event  is  not  scheduled. 
Described  in  the  context  of  the  event  list,  when  event  A  occurs  at  time  tA  and  i  is  true, 
event  B  is  added  to  the  event  list  at  time  tB  =  tA  +  today.  The  state  variables  of  the  system 
change  only  at  the  nodes  of  the  graph,  which  represent  the  events  that  are  capable  of 
changing  the  state  variables.  These  changes  to  state  variables  can  be  listed  below  the 
node  in  simple  cases.  More  complex  models  may  have  too  many  state  changes  to 
explicitly  list  each  and  every  one  below  its  associated  node. 
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Figure  7.  The  basic  Event  Graph  construct.  From  [Ref.14]. 


Event  Graphs  will  be  used  in  this  thesis  to  describe  the  simulation  model.  Two 
additional  features  of  the  Event  Graph  are  used  in  this  thesis:  these  are  canceling  edges 
and  the  passing  of  parameters  along  edges.  Canceling  edges  are  depicted  by  dashed  lines, 
and  indicate  that  the  occurrence  of  event  A  causes  the  removal  of  the  next  scheduled 
occurrence  of  event  B  from  the  event  list.  Passing  parameters  allows  information  about 
the  current  state  to  be  passed  to  future  events.  An  event  that  expects  and  requires  a 
parameter  has  the  type  of  parameter  (i.e.  int,  double.  Mover)  in  parentheses  below  the 
event  name.  Any  scheduling  edge  involving  a  passed  parameter  has  the  name  of  the 
parameter  inside  a  box  in  the  edge. 

B.  SIMKIT 

Simkit  is  a  simulation  tool  that  utilizes  the  Java  programming  language  to  build 
discrete-event  simulations.  Simkit  has  three  major  underlying  themes  that  will  be 
described  below:  loosely  coupled  components,  the  listener  pattern,  and  control  of 
information. 

Simkit  simulations  are  closely  related  to  the  Event  Graph.  Recall  that  the  nodes 
of  an  Event  Graph  correspond  to  the  events  that  describe  the  system.  The  Java  methods 
written  in  a  Simkit  simulation  have  roughly  the  same  name  as  the  events  on  the  Event 
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Graph.  The  word  “do”  is  simply  added  to  the  beginning  of  the  event  name  to  form  the 
method  name.  For  example,  the  Simkit  code  written  to  implement  Figure  7  would  have 
two  methods,  doA  and  doB. 

The  scheduling  arcs  of  the  Event  Graph  are  incorporated  into  Simkit  by  use  of  a 
“waitDelay”  statement  inside  a  “do”  method.  The  “waitDelay”  statement  includes  the 
name  of  the  event  to  be  scheduled,  the  time  to  delay  before  executing  the  event,  and  any 
parameters  to  be  passed  to  the  future  event.  An  example  of  a  completed  Java  method  for 
the  Event  Graph  in  Figure  7  is  as  follows. 

public  void  doA()  { 

if  (i)  { 

waitDelay  (B,  tDelay) ; 

} 

} 

Similarly,  the  canceling  edges  of  the  Event  Diagram  are  incorporated  into  Simkit 
by  use  of  an  “interrupt”  statement  inside  a  “do”  method.  The  “interrupt”  statement 
includes  the  name  of  the  event  to  be  canceled  and  any  parameters  to  be  passed  to  that 
event. 

Simkit  has  a  small  suite  of  components  ready-made  for  discrete-event  simulation. 
Examples  of  these  components  include  a  Basic  Mover  and  a  Cookie  Cutter  Sensor.  The 
Basic  Mover  moves  from  one  point  to  another  using  instantaneous  constant  velocity. 
When  a  Basic  Mover  reaches  the  point  it  was  moving  to,  it  stops  and  does  nothing  else 
unless  some  external  entity  provides  a  new  destination.  The  Cookie  Cutter  Sensor  is  a 
sensor  with  radial  range  of  R.  The  sensor  detects  targets  closer  than  R  units  away  with 
probability  1  and  detects  all  other  targets  with  probability  0. 

Simkit  is  based  on  the  concept  of  loosely  coupled  components.  That  is  to  say  that 
each  modular  component  is  responsible  for  executing  its  own  simple  task  and  typically 
requires  no  knowledge  of  the  source  of  its  inputs  or  what  is  done  with  its  outputs.  For 
example,  the  Basic  Mover  moves  to  whatever  coordinates  it  is  told  to  move  to  with  no 
concept  of  the  reason  why. 
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The  key  to  control  of  the  entities  in  Simkit  is  the  event  listener  paradigm.  The 
listener  construct  is  to  register  certain  entities  as  listeners  of  other  entities.  After  this 
registration,  the  listener  entity  will  “hear”  whenever  the  listened-to  entity  executes  a 
method.  In  those  cases  where  the  listener  has  a  method  of  the  same  name  as  that  just 
executed  by  the  listened-to  entity,  the  listener’s  method  will  also  be  executed.  For 
example,  an  entity  named  a  Mover  Manager  may  be  registered  to  listen  to  a  particular 
Basic  Mover.  When  the  Basic  Mover  executes  its  doEndMove  method,  the  Mover 
Manager  will  “hear”  the  doEndMove  method  of  the  Basic  Mover  and  will  execute  its 
own  doEndMove  method. 

Another  key  basis  for  Simkit  is  the  control  of  information.  The  thesis  Sensors  in 
Object  Oriented  Discrete  Event  Simulation  [Ref.  1 6]  contains  a  discussion  on  the  reasons 
to  control  access  to  information  in  a  simulation.  These  reasons  include  memoiy  savings, 
greater  fidelity  to  reality,  and  robustness  [Ref  14],  Simkit  approaches  this  need  to  control 
information  by  use  of  Referees.  The  purpose  of  the  Referee  is  to  arbitrate  the  interactions 
among  entities  in  the  simulation.  Multiple  Referees  may  be  required  in  keeping  with  the 
loosely  coupled  nature  of  Simkit,  with  each  Referee  being  responsible  for  only  one  type 
of  interaction.  An  example  of  the  need  for  a  Referee  is  the  interaction  between  a  Cookie 
Cutter  Sensor  and  a  Basic  Mover.  The  Cookie  Cutter  Sensor  needs  only  to  know  when  a 
target  has  been  detected;  indeed,  the  sensor  should  specifically  not  know  in  the  case  that  a 
target  was  close  to  entering  detection  range  R  but  then  stopped.  Likewise,  the  Basic 
Mover  has  no  reason  to  know  that  it  has  been  detected  by  the  sensor,  nor  to  know  that  it 
is  about  to  enter  the  sensor’s  detection  range.  This  interaction  is  controlled  by  a  Referee 
that  keeps  track  of  the  location  of  the  Basic  Mover  and  the  Cookie  Cutter  Sensor.  When 
the  Basic  Mover  enters  the  detection  range  of  the  Cookie  Cutter  Sensor,  the  Referee 
notifies  the  Cookie  Cutter  Sensor  of  the  location  of  the  Basic  Mover  and  tells  the  Basic 
Mover  nothing  about  the  existence  of  the  sensor,  thus  maintaining  the  logical  flow  of 
information  in  the  simulation. 

Chapter  IV  will  describe  the  use  of  Simkit  and  event  graphs  to  model  the  JTRS 
network.  It  will  also  discuss  the  scenario  developed  to  exercise  the  model. 
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IV.  DESCRIPTION  OF  MODEL  AND  SCENARIO 


This  chapter  gives  a  brief  description  of  the  model  constructed  to  simulate  the 
Marine  Corps  C4I  system  in  2015.  The  chapter  concludes  with  an  explanation  of  the 
OMFTS  scenario  used  to  demonstrate  the  model  and  for  analysis  of  bandwidth 
requirements.  The  aim  of  this  chapter  is  to  provide  an  understanding  of  the  functioning 
of  the  model  through  descriptions  the  use  of  Event  Graphs. 

A.  MODEL  DESCRIPTION 

The  system  to  be  modeled  is  similar  to  a  civilian  computer  network,  with  the 
exception  that  the  elements  in  this  network  move  across  a  battlefield.  Thus,  there  are  two 
major  functions  captured  by  the  model:  the  communication  function  and  the  movement 
function.  In  keeping  with  the  loosely  coupled  philosophy,  these  functions  are  separated 
from  each  other  to  the  greatest  extent  possible.  However,  since  the  functions  of  the 
network  are  strongly  dependent  on  the  actions  of  the  movement  components,  they  are 
more  tightly  coupled  than  most  Simkit  simulations. 

The  simulation  moves  entities  across  the  battlefield  generating  messages  of 
differing  priority,  depending  on  the  situation.  A  generated  message  must  flow  through 
the  network  to  get  to  its  intended  recipient.  Each  entity  has  a  limited  amount  of 
bandwidth  available  to  transmit  and  receive  messages  and  this  available  bandwidth  is 
reduced  as  a  function  of  the  size  of  any  messages  being  processed. 

When  a  message  is  transmitted  to  an  entity  that  lacks  the  available  bandwidth  to 
receive  that  message  (i.e.  the  entity  is  currently  handling  several  earlier  messages),  that 
message  will  be  “dropped”.  That  is  to  say  that  die  receiving  entity  will  not  receive  the 
message  and  will  not  know  that  it  missed  a  message.  However,  the  entities  do  have  the 
ability  to  store  both  generated  messages  and  previously  received  messages  for  later 
transmission.  Since  messages  are  stored  only  when  an  entity  is  fully  occupied  sending  or 
transmitting,  the  number  of  messages  waiting  to  be  sent  is  a  measure  of  the  load  on  the 
network.  Smaller  queues  indicate  a  smoothly  functioning  network,  with  bandwidth 
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capacity  in  reserve,  and  longer  queues  indicate  a  network  struggling  to  keep  up  with  the 
flow  of  message  traffic. 

Each  entity  keeps  a  list,  known  as  the  network,  of  all  entities  that  should  be  part  of 
the  communications  network.  Each  entity  also  keeps  a  separate  list,  known  as  the 
commList,  of  all  other  entities  that  it  is  currently  in  direct  communication  with.  The  sum 
of  the  information  contained  in  the  commLists  of  all  entities  describes  the  topology  of  the 
communications  network  at  any  given  time.  The  network  list  is  all  those  entities  that 
should  be  able  to  get  communications  to  each  other  across  the  network,  while  the 
commList  is  a  subset  of  the  network  list  of  only  those  in  direct,  “one-hop” 
communication  at  a  given  time.  The  network  list  does  not  change  throughout  the 
simulation,  while  every  commList  is  dynamic  and  does  change  as  the  scenario  unfolds. 

If  a  generated  message  is  intended  for  an  entity  on  the  generator’s  commList,  the 
message  is  sent  directly  to  that  entity.  If  the  recipient  is  not  on  the  sending  entities’ 
commList,  an  element  on  the  commList  is  selected  and  the  message  is  sent  to  that  entity 
in  the  hopes  that  this  new  holder  of  the  message  will  have  the  message’s  recipient  on  its 
commList.  This  process  is  repeated  until  the  message  reaches  the  recipient.  The  strength 
of  this  system  over  current  tactical  communications  is  that  one  unit  need  not  have  direct 
communication  with  another  in  order  to  pass  intelligence  or  request  support;  rather  a  unit 
only  needs  to  know  that  the  target  of  its  message  is  a  member  of  the  network. 

Receipts  are  generated  when  a  message  reaches  its  recipient.  Each  receipt  then 
transits  the  network  back  to  the  originator  of  the  message  for  which  the  receipt  was 
generated.  The  receipt  flows  through  the  network  using  the  exact  same  procedure  as  the 
original  message,  but  may  follow  a  different  path  to  reach  its  destination.  To  avoid 
unnecessary  and  unrealistic  network  saturation,  the  size  of  receipt  messages  is  set  to  0.1% 
of  the  capacity  of  a  JTRS. 

Each  message  transmitted  has  a  predetermined  delay  time  for  retransmission. 

After  that  delay,  the  message  will  be  retransmitted  unless  a  receipt  has  previously  arrived. 
This  feature  guards  against  the  fact  that  a  saturated  network  will  drop  some  messages. 

The  information  passed  in  every  message  is  considered  important,  so  the  model  attempts 
to  ensure  that  the  information  arrives  where  it  is  needed. 
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The  network  is  made  up  of  a  series  of  objects  of  the  type  JTRS.  Each  JTRS 
represents  the  command  and  control  hub  for  a  particular  military  unit  in  the  scenario. 

The  JTRS  object  is  a  container  for  a  collection  of  other  objects.  Among  these  are: 

1 .  ArrivalProcesses 

2.  QueueManager 

3.  Receiver 

4.  Transmitter 

The  listener  pattern  allows  each  component  to  perform  its  own  unique  function 
while  getting  information  it  needs  from  other  JTRS  components.  It  is  necessary  to  have 
an  understanding  of  the  functioning  of  each  component  before  discussing  the  actual 
listener  pattern  implementation  of  this  model. 

The  ArrivalProcesses  associated  with  each  JTRS  are  responsible  for  simulating 
the  occurrence  of  an  event  requiring  generation  of  a  message  at  the  unit.  The  JTRS  has 
an  array  of  ArrivalProcesses,  one  for  each  message  priority  level  that  exists  at  that 
particular  JTRS.  For  example,  in  the  case  where  a  JTRS  is  capable  of  generating 
message  of  priorities  Routine,  Immediate  and  Flash,  that  JTRS  would  have  three  separate 
ArrivalProcesses. 

The  ArrivalProcesses  in  this  simulation  assume  that  message  arrivals  constitute  a 
Poisson  process,  and  thus  have  exponential  inter-arrival  times.  The  model  has  the  ability 
to  change  the  arrival  rate  of  the  Poisson  processes,  depending  on  the  combat  situation  of 
the  JTRS.  However,  if  further  data  collection  by  the  Marine  Corps  indicates  that  a 
Poisson  process  is  not  the  best  way  to  model  the  arrival' of  messages  in  the  C4I  system, 
this  model  is  capable  of  switching  to  the  better  distribution  simply  by  replacing  the 
current  arrival  processes  with  new  ones.  This  is  a  case  of  increased  flexibility  thanks  to 
loosely  coupled  components:  The  JTRS  does  not  care  what  method  the  ArrivalProcesses 
are  using  to  generate  arrivals,  only  that  an  ArrivalProcess  says  “do Arrival.”  Figure  8  is 
the  Event  Graph  (See  [Ref.  13]  and  [Ref.  14])  of  the  ArrivalProcess. 
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Figure  8.  Event  Graph  for  ArrivalProcess. 


The  QueueManager  is  responsible  for  sorting  and  storing  all  messages  waiting  to 
be  sent  by  the  JTRS.  Messages  can  be  added  to  the  outgoing  queue  for  one  of  three 
reasons.  The  creation  of  a  message  by  the  JTRS  causes  that  message  to  be  queued.  The 
second  event  causing  a  message  to  be  queued  is  the  arrival  of  a  message  destined  for 
some  other  JTRS.  The  third  way  a  message  can  be  added  to  the  queue  is  if  a  message  has 
been  erroneously  sent  to  the  Transmitter  without  sufficient  bandwidth  to  actually  transmit 
the  message.  Figure  9  is  the  Event  Graph  for  the  QueueManager. 

The  QueueManager  sorts  messages  first  according  to  message  priority  and  then 
by  the  time  the  message  was  generated,  known  as  the  timestamp.  Messages  of  higher 
priority  are  placed  in  the  queue  ahead  of  all  messages  of  lower  priorities.  In  the  case  of 
messages  with  the  same  priority,  the  message  with  the  earliest  timestamp  enters  the  queue 
in  front  of  all  those  with  later  timestamps. 

Whenever  the  bandwidth  available  to  the  JTRS  increases,  or  a  message  is  added 
to  the  queue,  the  QueueManager  checks  the  queue  for  messages  to  be  sent.  A  message 
can  be  sent  if  its  bandwidth  requirement  is  less  than  the  bandwidth  available  to  the  JTRS 
and  the  message  does  not  have  special  instructions  to  be  sent  only  at  a  later  time.  The 
QueueManager  steps  through  the  queue  until  either  a  message  that  can  be  sent  or  the  end 
of  the  queue  is  reached.  If  the  queue  contains  a  message  that  can  be  sent,  the 
QueueManager  removes  that  message  from  the  queue  and  sends  it  to  be  transmitted, 
which  in  turn  causes  the  available  bandwidth  of  the  JTRS  to  be  decreased.  The 
QueueManager  then  checks  the  queue  again,  comparing  message  sizes  to  the  current. 
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decreased  bandwidth  available.  This  process  is  continued  until  the  queue  is  empty  or  the 
QueueManager  reaches  the  end  of  the  queue  without  finding  a  message  to  send.  That  is 
to  say,  until  all  messages  in  the  queue  have  been  sent  to  be  transmitted,  or  until  there  are 
no  messages  in  the  queue  that  can  be  transmitted  with  the  bandwidth  remaining. 

The  final  function  of  the  QueueManager  is  to  remove  specific  messages  from  the 
queue  when  told  to  do  so.  The  model’s  usage  of  this  function  is  to  remove  messages 


scheduled  for  retransmission  at  a  later  time  if  a  receipt  for  that  message  arrives  before  the 
retransmission  time. 


Figure  9.  Event  Graph  for  QueueManager. 

The  Receiver  class  receives  messages  from  transmitters  within  communication 
range  of  its  JTRS.  Upon  arrival  of  a  message,  die  Receiver  notifies  the  JTRS  of  the  size 
of  the  message.  This  causes  the  bandwidth  available  to  the  JTRS  to  be  immediately 
decreased  by  the  size  of  the  message.  The  Receiver  also  causes  the  JTRS  to  schedule  die 
return  of  the  bandwidth  committed  to  receiving  the  message  after  a  time  delay  equal  to 
the  time  spent  receiving  the  message.  Figure  10  is  the  Event  Graph  for  the  Receiver. 
Each  received  message  is  categorized  by  the  Receiver  as  one  of  the  following 

types: 
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1 .  For  this  JTRS  and  as  a  receipt  for  a  previously  sent  message. 

2.  For  this  JTRS  and  not  as  a  receipt. 

3.  Not  for  this  JTRS. 

A  message  of  type  1  causes  the  Receiver  to  notify  the  QueueManager  to  remove 
the  message  scheduled  for  retransmission  from  the  queue.  A  message  of  type  2  causes 
the  Receiver  to  generate  a  receipt  and  to  send  the  receipt  to  the  QueueManager  for 
addition  to  the  queue.  A  message  of  type  3  is  sent  immediately  to  the  QueueManager. 

The  Transmitter  object  gets  messages  from  the  QueueManager  and  broadcasts 
them  to  Receivers  within  communication  range.  Each  message  sent  to  the  Transmitter  is 
evaluated  to  ensure  the  JTRS  has  sufficient  bandwidth  to  send  the  message.  If  the 
bandwidth  available  is  greater  than  that  needed  to  send  the  message,  the  Transmitter  send 
the  message  to  one  of  the  Receivers  within  communication  range.  The  Transmitter  picks 
a  Receiver  to  send  to  by  first  checking  to  see  if  any  elements  on  the  commList  are  the 
intended  recipient  of  the  message,  in  which  case  the  Transmitter  sends  to  that  Receiver. 

If  the  message’s  recipient  is  not  on  the  commList,  the  Transmitter  arbitrarily  picks  a 
Receiver  on  the  commList  and  sends  the  message.  The  Transmitter  takes  exactly  the 
same  steps  as  the  Receiver  to  help  the  JTRS  keep  track  of  current  bandwidth  available. 
Figure  1 1  is  the  Event  Graph  for  the  Transmitter. 

In  addition  to  containing  the  above  components,  each  JTRS  also  handles  three 
specific  functions.  The  first  of  these  is  to  generate  message  objects  when  the 
ArrivalProcess  has  an  arrival.  The  second  function  of  the  JTRS  is  to  track  its  own 
bandwidth  available.  This  is  done  by  listening  to  the  Receiver  and  Transmitter  as  they 
announce  the  size  and  duration  of  each  message.  The  final  function  is  to  accept  changes 
to  the  situation  by  changing  the  arrival  rates  of  the  ArrivalProcesses.  This  function 
allows  the  simulation  of  differing  intensities  of  action  and  combat.  The  Event  Graph  for 
the  JTRS  is  shown  in  Figure  12. 
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Figure  10.  Event  Graph  for  Receiver. 
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Figure  11.  Event  Graph  of  Transmitter. 


Figure  13  shows  the  listener  pattern  used  by  the  network.  Information  flows  in 
the  direction  of  the  arrows,  that  is  the  object  at  the  point  of  the  arrow  is  the  listener  and 
listens  to  the  object  at  the  origin  of  the  arrow.  The  plain  bold  arrows  indicate  how  the 
components  of  a  single  JTRS  interact.  The  bent  arrow  indicates  a  listener  pattern  set  up 
between  JTRSs.  Each  Receiver  is  a  listener  to  all  Transmitters  of  the  JTRSs  on  the 
Receiver’s  JTRS’s  commList.  This  enables  the  transmission  of  messages  between  the 
elements  of  the  network. 


Figure  13.  Listener  pattern  for  communication  network. 


The  movement  of  the  JTRS  sets  around  the  battlefield  is  accomplished  by 
associating  each  JTRS  with  a  unique  Mover  object.  The  JTRS  in  effect  “rides”  on  the 
Mover.  The  following  are  two  additional  objects  contained  in  the  JTRS: 

1.  CommMover 

2.  BasicSensor 

The  BasicMover  is  a  class  provided  in  Simkit  and  moves  only  in  a  straight  line 
from  one  point  to  another,  with  instantaneous  and  constant  velocity.  The  BasicMover  is 
provided  a  destination  by  another  Simkit  class,  the  PathMoverManager.  Once  the 
BasicMover  arrives  at  its  destination  it  announces  doEndMove,  which  is  heard  by  the 
PathMoverManager,  who  in  turn  passes  the  next  point  for  the  BasicMover  to  move  to. 
The  PathMoverManger  is  provided  by  the  user  a  list  of  coordinates  which  describe  the 
path  of  the  BasicMover.  Once  the  PathMoverManager  stops  sending  new  coordinates  to 
the  BasicMover,  the  mover  stops. 

The  network  topology  is  described  by  the  sum  of  the  information  contained  in  ail 
of  the  commLists  maintained  by  the  JTRSs  in  the  simulation.  The  JTRS  keeps  track  of 
its  own  commList  by  using  an  extension  of  another  Simkit  process. 
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Simkit  comes  equipped  with  the  BasicSensor,  which  is  a  cookie  cutter  sensor,  as 
discussed  in  Chapter  HI.  The  BasicSensor  is  built  to  locate  Movers,  of  which 
BasicMover  is  a  sub-class,  and  so  can  be  detected.  Simkit  also  includes  a  Referee  class  to 
keep  track  of  interactions  among  entities,  and  a  CookieCutterMediator  to  mediate  the 
interactions  identified  by  the  Referee. 

The  Referee  and  the  CookieCutterMediator  ensure  that  no  undeserved 
information  is  passed  to  either  the  Mover  or  the  BasicSensor,  in  keeping  with  the 
information  protecting  principle  of  Simkit.  Specifically,  any  Mover  detected  by  the 
BasicSensor  is  not  passed  directly  to  the  BasicSensor,  rather  a  new  object  called  a  contact 
is  passed  to  the  BasicSensor.  This  prevents  the  BasicSensor  from  having  access  to  the 
methods  and  variables  of  the  Mover,  as  could  be  the  case  if  an  actual  reference  to  the 
Mover  was  passed  instead  of  the  contact.  These  contacts  are  recorded  by  the  BasicSensor 
on  a  DetectionList.  The  Referee  and  CookieCutterMediator  together  keep  the 
BasicSensor’s  DetectionList  up  to  date,  adding  contacts  as  they  enter  range  and  removing 
contacts  from  the  list  as  they  exit  range. 

The  nature  of  this  problem  is  somewhat  different  in  that  the  JTRSs  are 
cooperative  and,  once  in  range,  they  will  want  to  share  their  identities  in  order  to  update 
commLists  and  pass  messages.  Three  actions  are  required  to  change  the  existing  Simkit 
methods  to  support  this  simulation.  First,  the  CookieCutterMediator  is  extended  by  a 
new  CommLinkMediator  class.  This  new  class  passes  an  actual  reference  to  the  Mover 
detected  by  the  BasicSensor,  rather  than  a  contact.  Secondly,  the  BasicMover  is  extended 
by  a  CommMover  class.  This  CommMover  class  differs  from  a  BasicMover  in  that  the 
CommMover  is  built  to  carry  a  J  IKS  and  knows  that  it  is  associated  with  a  particular 
JTRS.  The  association  of  an  entity  to  a  BasicMover,  on  the  other  hand  is  one-way  only; 
the  riding  entity  knows  it  is  associated  with  a  BasicMover,  but  the  BasicMover  does  not 
know  about  its  rider.  The  final  step  to  maintaining  the  commList  is  for  the  JTRS  to  ask  its 
BasicSensor  for  the  sensors  DetectionList.  Because  of  the  CommLinkMediator,  this  is 
actually  a  list  of  all  CommMovers  within  range  of  this  JTRS.  Because  these  are 
CommMovers,  and  are  thus  aware  of  carrying  a  JTRS,  they  can  report  a  reference  to  the 
JTRS  they  are  associated  with.  The  JTRS  simply  gets  the  DetectionList  from  its 
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BasicSensor,  polls  each  CommMover  on  the  DetectionList  to  learn  the  identity  of  the 
CommMover’s  JTRS,  and  adds  that  JTRS  to  the  commList.  The  Referee  and 
CommLinkMediator  will  keep  the  BasicSensor’s  contactList  current  and  accurate,  which 
will  in  turn  allow  the  JTRS  to  keep  an  accurate  commList. 

B.  SCENARIO  DESCRIPTION 

The  simulation  developed  for  this  thesis  is  flexible  enough  to  be  applied  to  a 
myriad  of  communication  networking  situations.  A  single  representative  STOM  scenario 
will  be  detailed  in  this  section  and  the  results  of  that  scenario  examined  in  Chapter  V. 

The  scenario  is  constructed  to  include  all  of  the  communications  challenges  of  STOM 
and  to  fully  exercise  the  simulation. 

The  year  is  201 5  and  a  U.S.  naval  amphibious  force  is  located  off  the  coast  of  a 
hostile  country,  prepared  to  conduct  operations  in  support  of  national  interests.  The 
landing  force  is  composed  of  elements  of  the  8th  Marine  Regiment  (8MAR)  and  2nd  Tank 
Battalion  (2TkBn).  All  forces  are  equipped  with  WLAN  at  the  company  level  and  with 
JTRS  for  communication  above  the  company  level.  Each  battalion  will  conduct  the 
attack  with  three  companies  on  the  ground,  plus  a  battalion  headquarters.  For  clarity  the 
units  are  referred  to  by  their  battalion  headquarters’  names,  although  all  units  would 
actually  be  task  organized,  with  elements  attached  and  detached  as  the  situation  indicates. 

The  commander’s  estimate  of  the  situation,  aided  by  national  and  theater  level 
intelligence,  is  that  the  enemy  will  likely  lose  the  will  to  fight  if  his  capital  is  seized.  As 
a  result  of  this  estimate,  an  operations  order  has  been  prepared,  assigning  8th  Marines  the 
mission  of  seizing  two  objective  areas.  Objective  A  (OBJ  A)  is  the  capital  itself  and  OBJ 
B  is  a  military  barracks  that  can  be  expected  to  attempt  to  reinforce  the  capital’s  garrison 
force. 

The  operations  order  calls  for  a  supporting  attack  by  1st  Battalion,  8th  Marines 
(1/8)  against  OBJ  B  and  the  main  attack  by  2nd  Tank  Battalion  (2TkBn)  and  2nd  Battalion, 
8th  Marines  (2/8)  to  seize  OBJ  A.  The  supporting  attack  is  scheduled  for  0100  local  time, 
and  must  take  place  before  the  main  attack  on  OBJ  A  starts.  It  is  expected  to  take  90 
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minutes  of  combat  to  secure  OBJ  B  to  the  extent  that  the  main  attack  can  hit  OBJ  A 
without  fear  of  enemy  reinforcements,  and  an  additional  60  minutes  to  complete  the 
seizure  of  OBJ  B.  Given  that  OBJ  B  cannot  reinforce  OBJ  A,  it  is  expected  to  take  90 
minutes  of  combat  to  defeat  the  garrison  force  at  OBJ  A. 

Table  1  lists  friendly  forces  for  this  operation.  The  Trans  column  indicates  which 
member  of  the  mobility  triad  will  be  used  for  the  Ship-To-Objective  movement.  In  the 
case  of  the  tanks,  LCAC  transportation  will  be  used  to  get  to  the  shore  and  from  then  on 
the  mobility  of  the  tanks  themselves  will  be  used.  Speed  refers  to  the  expected  rate  of 
unopposed  advance  for  each  unit.  Speed  listed  in  the  form  speedl/speed2  refer  to  the 
different  speeds  on  water  and  on  land,  and  can  be  read  as  waterspeed/landspeed. 


Unit 

Location 

Objective 

Trans 

Speed  (Kts) 

8th  Marine  Regiment 

Shipping 

NA 

NA 

NA 

1st  Battalion,  8th  Marines 

Shipping 

B 

V-22 

210/2 

2nd  Battalion,  8th  Marines 

Shipping 

A 

AAAV 

20/25 

2nd  Tank  Battalion 

Shipping 

A 

LCAC 

40/25 

Table  1.  Friendly  forces.  8th  Marines  Headquarters  will  remain  aboard  shipping. 


Figure  14  is  a  rough  diagram  of  the  scheme  of  maneuver.  The  assault  will  come 
from  over  the  horizon,  keeping  the  support  elements  and  shipping  safe  from  land  based 
threats.  The  amphibious  force  is  currently  approximately  50  nautical  miles  offshore. 

OBJ  B,  the  military  barracks  is  another  30  nautical  miles  inland,  while  OBJ  A,  the 
capital,  is  125  nautical  miles  from  the  coast. 

The  JTRSs  in  this  scenario  have  their  maximum  range  set  to  35  nautical  miles. 

The  extended  distance  of  175  nautical  miles  will  require  pre-planned  relay  stations  in 
order  to  maintain  communications.  The  8th  Marines  Regimental  Communications  Officer 
has  planned  for  a  series  of  relay  stations  between  the  two  objectives  and  the  command 
element  aboard  shipping.  The  relay  equipment  and  personnel  will  accompany  the  assault 
forces  with  the  main  attack,  and  will  start  relaying  when  the  force  arrives  at  each  relay 

station’s  designated  location.  The  relay  stations  in  support  of  the  attack  on  OBJ  B  will  be 
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inserted  prior  to  the  attack,  thus  ensuring  that  they  will  be  ready  to  relay  when  the  assault 
occurs.  The  coordinates  of  the  Objectives,  Amphibious  Force,  and  the  Relay  Sites  are 
listed  in  Table  2. 


Figure  14.  Ground  Combat  Element  scheme  of  maneuver. 


Unit/Objective 

Location 

Amphibious  Force  &  8th  Marines 

(0.0 , 0.0) 

Relay  1 

(21.21 ,21.21 

Relay  2 

(42.42 , 42.42) 

Relay  3 

(63.63 , 63.63) 

Relay  4 

(84.84 , 84.84) 

Relay  5 

(106.05 , 106.05) 

Objective  A 

(123.74,123.74) 

Relay  6 

(23.1  ,  13.33) 

Relay  7 

(46.2 , 26.66) 

Objective  B 

(69.28 , 40.0) 

Table  2.  Location  of  Relay  Sites  and  Objectives. 
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The  simulation  has  a  total  of  13  entities  on  the  battlefield,  four  per  battalion  and 
the  Regimental  Headquarters.  There  are  three  levels  of  communications  intensity  for 
each  entity  in  this  scenario.  Each  level  of  intensity  is  described  by  both  the  frequency  of 
messages,  and  the  urgency  or  priority  of  the  messages  generated.  Frequency  is  a  measure 
of  the  arrival  rate  of  messages  in  the  ArrivalProcess.  The  urgency  of  messages  is  a 
description  of  the  distribution  of  messages  between  the  priority  levels  modeled 

The  first  communication  intensity  level,  low  intensity,  is  low  frequency,  low  to 
middle  priority.  This  level  is  the  default  at  the  start  of  the  simulation  and  is  the  level  of 
intensity  expected  during  an  unopposed  movement,  where  messages  are  infrequent  and  of 
a  routine  nature.  The  second  level,  middle  intensity,  corresponds  to  a  tactical  movement 
to  contact,  in  which  the  unit  is  covering  previously  unseen  terrain  and  is  unsure  of  the 
location  of  the  enemy.  Messages  are  more  frequent  than  the  first  level,  but  retain  the 
same  proportions  of  arrival. 

The  last  and  highest  communications  intensity,  high  intensity,  is  high  frequency 
and  high  priority.  This  is  the  level  that  reflects  a  unit  in  actual  combat.  Message  arrival 
rates  peak  and  the  priority  of  these  messages  is  very  high.  Very  few  low  priority 
messages  are  even  generated,  which  is  an  attempt  by  the  simulation  to  model  the  real 
changes  that  occur  on  communication  networks  when  engaged  in  combat.  Table  3  details 
the  interarrival  times  sent  to  the  arrival  processes. 

In  this  scenario  each  battalion  is  assumed  to  have  the  same  communication 
intensity  throughout  its  sub-units.  It  is  possible  to  set  each  entity’s  communication 
intensity  individually.  However,  for  the  sake  of  simplicity  in  the  scenario,  each  battalion 
changes  communication  intensity  as  a  ’whole. 


39 


Communications  Intensity 

Message  Priority 

Mean  Interarrival 

Time  (Minutes) 

LOW 

High 

60.0 

Middle 

6.0 

Low 

3.0 

MID 

High 

12.0 

Middle 

1.2 

Low 

0.6 

HIGH 

High 

0.3 

Middle 

0.6 

Low 

6.0 

Table  3.  Interarrival  times  of  messages.  Model  varies  times  as  intensity  changes. 


All  units  start  the  simulation  at  the  low  intensity  setting.  First  Battalion,  8th 
Marines,  the  unit  conducting  the  supporting  attack  on  OBJ  B,  remains  at  low  intensity 
until  landing  on  OBJ  B,  at  which  point  the  unit  changes  to  high  intensity.  The  main 
attack  changes  to  mid  intensity  once  landfall  is  made  and  the  movement  to  OBJ  A  begins. 
Upon  reaching  OBJ  A,  the  main  attack’s  intensity  changes  to  high  intensity.  The 
headquarters  element’s  intensity  level  is  set  to  be  the  maximum  intensity  level  of  any 
subordinate  unit. 

All  units  start  collocated  with  the  Regimental  Headquarters.  2/8  in  AAA  Vs 
moves  first,  followed  by  2TkBn  on  LCACs,  phased  so  that  both  forces  arrive  at  the  beach 
at  the  same  time  and  location  and  can  move  toward  OBJ  A  together.  1/8’s  attack  on  OBJ 
B  is  scheduled  for  0100  and  the  main  attack  is  scheduled  for  0300.  This  timing  allows  a 
30-minute  delay  beyond  the  90  minutes  predicted  for  1/8  to  accomplish  its  mission  while 
seeking  to  maximize  the  confusion  of  the  enemy  by  nearly  simultaneous  attacks.  Table  2 
shows  the  scenario’s  assault  timeline. 
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Time 

Event 

1930 

2/8  starts  movement  to  shore 

2045 

2TkBn  starts  movement  to  shore 

2200 

2/8  and  2TkBn  ashore,  starts  movement  to  OBJ  A 

0038 

1/8  starts  movement  to  OBJ  B 

0100 

Assault  on  OBJ  B 

0230 

Expected  conclusion  of  battle  on  OBJ  B 

0300 

Assault  on  OBJ  A 

0430 

Expected  conclusion  of  battle  on  OBJ  A 

Table  4.  Assault  timeline. 


The  scenario  will  be  simulated  from  the  movement  of  the  first  unit  to  the  expected 
conclusion  of  the  battle  on  OBJ  A. 

The  MOE  for  the  scenario  is  a  weighted  penalty  function  assigns  a  cost  for  each 
late  message.  The  Penalty  Function  assigns  a  base  cost  of  one  to  a  late  low  priority 
message.  A  late  middle  priority  message  is  three  times  as  costly,  and  a  late  high  priority 
message  is  five  times  as  costly,  as  a  late  low  priority  message.  The  model  also  defines 
late  differently  for  each  priority  of  message,  as  indicated  below: 

PENALTY  P  =  5*H  +  3*M  +  1*L 

Where  H  =  Number  of  high  priority  messages  not  delivered  within  1  minute. 

M  =  Number  of  middle  priority  messages  not  delivered  within  3  minutes. 

L  =  Number  of  low  priority  messages  not  delivered  within  10  minutes 

A  special  purpose  Java  class,  PenaltyCalculator  was  constructed  to  manage  the 

MOE.  The  count  of  late  messages  is  tracked  during  the  simulation  scenario  by 

calculating  the  time  to  delivery  of  each  message  that  arrives  at  the  Receiver  of  the  JTRS 

that  is  the  target  of  the  message.  If  the  current  simulation  time  minus  the  timestamp  of 

the  message  minus  the  transmission  time  of  the  message  exceeds  the  delivery  threshold, 

the  PenaltyCalculator  is  notified  and  records  the  late  delivery.  The  Penalty  Function  only 

considers  those  messages  sent  between  8th  Marines  and  die  three  battalion  headquarters  in 
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computing  the  count  of  late  messages.  Intra-battalion  messages  do  not  count  against  the 
systems  performance. 

After  the  simulation  is  complete,  the  queue  of  each  QueueManager  is  checked  for 
undelivered  late  messages  and  the  PenaltyCalculator  updates  the  MOE.  The  final  Penalty 
is  reported  at  the  end  of  the  scenario. 

The  effects  of  varying  the  bandwidth  of  the  relay  sites  will  be  examined  by 
observing  corresponding  changes  in  the  Penalty  Function.  Due  to  the  lack  of  good 
communications  data,  this  bandwidth  is  described  as  a  multiple  of  the  bandwidth 
associated  with  a  normal  JTRS  node.  In  other  words,  two  relay  sites  might  be  described 
as  having  bandwidth  of  1.0  and  1.5  respectively,  which  is  to  say  that  the  first  relay  site 
has  the  same  bandwidth  as  all  non-relay  JTRS  nodes  in  the  network,  while  the  second  has 
1 50%  of  the  bandwidth  of  non-relay  nodes. 

The  scenario  will  also  be  modified  to  examine  the  effects  of  parallel  relay  sites. 
This  will  be  modeled  by  adding  a  second  relay  site  at  each  relay  position  listed  in  Table 
2.  The  results  of  the  basic  scenario,  along  with  this  modification  are  presented  in  Chapter 
V. 
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V.  SCENARIO  RESULTS 


The  reason  for  developing  this  simulation  was  to  examine  the  bandwidth 
requirements  of  the  JTRS  in  support  of  a  STOM  scenario.  It  was  believed  that  the  relay 
sites  in  the  scenario  would  be  the  weak  links  in  the  communication  network.  The  actual 
results  of  the  simulation  do  not  support  that  belief.  The  surprising  result  was  that  the 
effectiveness  of  the  network,  as  measured  by  the  penalty  function,  was  relatively 
insensitive  to  the  bandwidth  of  the  relay  sites.  This  chapter  will  explore  both  the  results 
of  the  scenario  and  will  use  a  simplified  expected  value  analysis  to  examine  these 
counter-intuitive  results. 

A.  BASIC  SCENARIO 

The  model  was  extremely  sensitive  to  the  arrival  rates  of  messages.  The  arrival 
rates  used  in  the  scenario  were  decided  upon  by  testing  the  network  when  all  units  were 
co-located  and  so  were  assured  of  being  able  to  reach  the  target  of  any  message  in  one 
hop.  The  network  held  up  under  low  and  mid  communications  intensity  levels,  but 
queues  built  up  when  set  to  the  high  intensity  level.  This  queuing  was  a  desired  feature 
of  the  model  and  is  intended  to  portray  the  stress  of  combat  on  the  network. 

No  matter  what  arrival  rates  were  presented  to  the  model,  it  remained  insensitive 
to  relay  bandwidth.  The  Penalty  Function  rises  when  more  messages  arrive  in  the  system 
and  falls  when  the  arrival  rate  is  lower,  but  within  each  arrival  rate  die  Penalty  Function 
remains  insensitive  to  relay  bandwidth  changes. 

The  value  gained  from  the  model  is  exactly  that  it  did  not  behave  as  expected. 

This  caused  additional  examination  of  the  system  being  modeled  and  the  model  being 
used.  Detailed,  but  of  course  less  than  exhaustive,  exploration  of  the  model’s  behavior 
indicates  that  it  is  behaving  as  described  in  Chapter  IV. 

In  testing  the  effects  of  relay  bandwidth  on  the  penalty  function,  a  total  of  20  trials 
were  run  at  each  of  several  relay  bandwidth  level.  Columns  two  and  three  of  Table  5 
show  the  mean  and  standard  deviation  of  the  penalty  function  at  the  bandwidth  level 
indicated  in  column  one.  Column  four  is  a  nonparametric  approximate  90%  confidence 
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interval  for  the  median  based  on  the  binomial  distribution,  as  described  and  tabled  in 
Practical  Nonparametric  Statistics  [Ref.  17],  Figure  15  is  a  graphical  depiction  of  the 
point  estimators  of  the  mean  penalty  function  at  each  level  of  bandwidth. 

Special  attention  is  drawn  to  the  case  in  which  relay  bandwidth  was  set  to  0.0. 
The  Penalty  Function  in  this  case  is  calculated  from  the  total  number  of  messages 
generated  when  relay  was  required.  During  significant  portions  of  the  scenario  the  two 
battalion  headquarters  and  8th  Marines  were  within  radio  range  of  each  other  and  so  did 
not  require  relay.  The  results  in  Table  5  seem  to  indicate  that  the  Penalty  Function 
variations  between  the  bandwidth  levels  is  a  result  of  noise  in  the  simulation  and  not 
because  of  any  response  change  as  a  result  of  relay  bandwidth  changes 


Relav  bandwidth 

Mean  Penalty 

Function 

S.D.  of  Penalty 

Function 

90%  Cl  for  median  of  Penalty 

Function 

0.0 

878.6 

324.8 

(719, 852) 

.25 

776.2 

156.3 

(689 , 784) 

.5 

805 

171.1 

(696 , 897) 

1 

849.9 

310.8 

(706 , 778) 

2 

936.1 

427.5 

(636, 971) 

5 

766.7 

305.4 

(613 , 834) 

Table  5.  Results  of  simulaton  runs. 


A  nonparametric  median  test  was  performed  [Ref.  17]  on  the  six  bandwidth 
levels.  The  purpose  of  the  median  test  is  to  determine  if  several  samples  came  from 
populations  having  the  same  median  [Ref.  1 7],  which  is  the  null  hypothesis.  If  the  null 
hypothesis  is  not  rejected  in  this  case,  it  would  indicate  that  the  Penalty  Function 
variations  observed  in  the  simulation  runs  are  a  result  of  normal  random  fluctuations  in 
the  simulation,  rather  than  a  change  in  the  underlying  distribution. 

The  procedure  calls  for  pooling  all  data  and  determining  the  median  of  that  group, 
which  is  referred  to  as  the  grand  median.  Each  sample  is  then  divided  into  two  groups: 
those  observations  above  the  grand  median  and  those  at  or  below  the  grand  median.  The 
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number  from  each  sample  in  either  group  (above  median  or  not)  are  then  tabled  See 
Table  6  for  the  results  from  the  simulation  output. 


Figure  15.  Penalty  Function  mean  value  vs.  JTRS  relay  bandwidth 


Sample  Bandwidth 

0.0 

0.25 

0.5 

1.0 

2.0 

5.0 

Totals 

>Median 

12 

11 

9 

12 

9 

7 

<=Median 

8 

9 

11 

8 

11 

13 

b=60 

Totals 

20 

20 

20 

20 

N 

Table  6.  Median  Test  cell  counts. 

When  a=b,  as  in  this  case,  the  test  statistic  T  for  the  Median  Test  is  computed  as 
follows: 


T  _  ^  (Oi»  ~  _  ^  l  )  2 


Where: 

c  is  the  column,  or  population  from  which  a  random  sample  was  drawn. 
0Xi  is  the  number  of  observations  in  row  1  or  row  2  in  column  i. 
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ns  is  the  size  of  the  random  sample  drawn  from  the  i*  population. 

In  this  case  all  n;  =  20. 

Under  the  null  hypothesis  that  the  samples  all  come  from  populations  with  the 
same  median,  T  is  distributed  is  as  follows:  T  ~  xl-\ 

The  test  statistic  is  3.45.  The  p-value  for  a  result  of  3.45  from  a  Chi-squared 
distribution  with  6-1—5  degrees  of  freedom  is  .6309.  Therefore  we  can  not  reject  the  null 
hypothesis  that  the  six  samples  came  from  distributions  with  the  same  mean. 

Both  Table  5  and  Figure  15  indicate  that  significant  changes  to  the  relay 
bandwidth  do  not  cause  corresponding  significant  changes  to  the  penalty  function.  There 
are  two  possible  explanations  for  this  model  behavior.  Either  the  model  is  not  correctly 
simulating  the  true  nature  of  the  system,  or  the  real  system  may  behave  this  way.  It  is 
likely  that  both  of  these  possible  explanations  are  at  least  somewhat  true  and  in 
combination  yield  this  surprising  result. 

It  is  possible  that  the  simplistic  message  routing  scheme  and  description  of 
bandwidth  used  in  this  model  may  be  causing  behavior  that  is  not  consistent  with  the  real 
system.  The  system  being  simulated  is  so  large  and  has  so  many  actions  and  interactions 
that  some  level  of  abstraction  is  necessary  in  order  to  produce  a  simulation  that  can  be 
run  on  a  desktop  computer. 

The  results  of  the  parallel  relay  system  are  actually  worse  than  for  single  relays. 
This  too  may  be  caused  by  the  way  in  which  the  model  picks  where  to  route  messages; 
parallel  relay  sites  allow  more  choices  for  routing  and  increase  the  probability  that  a 
message  will  go  the  “wrong”  direction.  Given  the  model’s  demonstrated  insensitivity  to 
any  changes  in  relay  bandwidth,  it  should  not  be  surprising  that  adding  bandwidth  to  the 
relay  positions  did  not  help  the  Penalty  Function  at  all. 

Regardless  of  this  result,  a  parallel  relay  system  is  more  robust  than  a  single  relay 
system  in  real-world  operations.  Equipment  failures  and  enemy  actions  can  be  expected 
to  occasionally  cause  the  loss  of  a  relay  site  to  the  network.  In  the  single  relay  system, 
this  has  the  potential  to  cause  elements  of  the  network  to  be  isolated  from  the  rest  of  the 
network  if  the  failure  occurs  at  a  key  relay  node.  The  primary  factor  favoring  the  single 
relay  system  is  cost.  If  system  A  has  half  the  bandwidth  capacity  of  system  B,  but  costs 
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75%  of  the  cost  of  B,  then  A  will  never  be  favored  from  a  financial  standpoint;  simple 
algebra  tells  us  that  each  “unit”  of  bandwidth  is  50%  more  expensive  for  system  A  than 
for  system  B.  Because  of  this  financial  unattractiveness,  system  A  is  unlikely  to  be 
selected  as  the  system  of  choice,  despite  the  tactical  flexibility  and  robustness  it  brings. 

It  is  remains  possible  that  the  real  network  itself  may  be  fairly  insensitive  to  relay 
bandwidth,  especially  at  the  high  intensity  communications  level.  This  possibility  is 
examined  in  the  next  section. 

B.  SPECIAL  CASE  ANALYSIS 

Each  battalion  headquarters  in  the  scenario  is  dealing  with  a  higher  headquarters 
and  three  subordinate  units.  It  is  not  unrealistic  to  believe  that  in  high  an  intensity  period 
of  combat  that  the  battalion  headquarters  will  be  the  limiting  nodes,  rather  than  the  relay 
sites.  The  battalion  headquarters  are  dealing  with  frequent  and  urgent  exchanges  of 
information  between  themselves  and  three  subordinate  units,  as  well  as  equally  frequent 
and  urgent  exchanges  with  the  regimental  headquarters.  On  the  other  hand,  the  relay  sites 
are  only  handling  the  traffic  between  battalion  and  regimental  headquarters  and  are  not 
producing  any  bandwidth-reducing  messages  of  their  own.  Once  the  battalion 
headquarters  is  saturated,  the  Penalty  Function  climbs,  regardless  of  the  performance  of 
the  relay  suites.  This  may  be  a  case  of  the  simulation  accurately  modeling  the  system 
under  study,  despite  the  original  expectations  of  the  modeler. 

An  analytical  examination  of  the  normal  scenario  is  not  possible;  but  in  a  special 
case,  the  nature  of  the  arrival  processes  can  be  exploited  to  gain  some  insight  into  the 
relative  traffic  load  at  specific  nodes  in  die  network.  This  case  is  the  one  in  which  the 
probability  that  a  unit  (other  than  8th  Marines)  sends  a  message  to  its  own  higher 
headquarters  is  1 .0.  This  probability  was  set  to  .5  for  all  units  except  8th  Marines  for  the 
basic  scenario,  and  is  changed  here  for  purposes  of  analysis.  8th  Marines  continues  to 
send  messages  to  any  member  of  the  network  with  equal  probability. 

A  further  simplification  made  for  purposes  of  analysis  is  that  each  element  sends 
messages  along  the  correct  edge  for  it  to  reach  its  target.  This  is  not  how  the  model 
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works,  but  will  provide  for  ease  of  analysis.  Figure  16  is  the  approximate  topology  of  the 
network  when  the  battle  at  OBJ  B  is  underway.  Arrows  indicate  the  flow  of  messages  as 
required  by  the  100%  -to-headquarters  rule.  Note  that  1/8  and  its  subordinate  units  are  all 
in  range  of  Relay  1 02. 

We  will  examine  the  relative  loads  on  1/8  and  Relay  102.  Because  1/8  is  in 
combat,  intensity  is  set  to  high  for  1/8  and  8th  Marines.  No  messages  from  2TkBn  or  2/8 
will  reach  Relay  102  or  1/8,  because  they  will  all  be  sent  to  a  battalion  headquarters  or 
the  8th  Marines. 

The  interarrival  times  for  high  communications  intensity  are:  .3,  .6,  6.0  (minutes) 
for  high,  mid,  and  low  priority  messages.  We  will  aggregate  all  messages  into  a  single 
arrival  rate.  The  arrival  rate  of  the  Poison  process  is  1 /(interarrival  time).  That  means 
that  we  can  expect  each  non-relay  JTRS  to  produce: 

60(l/.3  +  1/.6+1/6.0)  =  310  messages  per  hour 


Figure  16.  Network  topology  during  the  battle  for  OBJ  B. 


8th  Marines  will  pick  message  targets  at  random,  with  probability  1/3  that  it  will 
send  a  message  in  the  direction  of  2/8  (4/12  possible  targets  in  that  direction).  1/4  of  the 
messages  from  8  Marines  will  be  for  First  Battalion,  8**1  Marines,  for  a  cumulative 
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fraction  of  1/12  of  the  messages  from  8th  Marines  expected  to  be  sent  through  Relay  102 
to  1/8. 

Relay  102  will  also  have  100%  of  the  messages  from  1/8  sent  through  itself  on 
their  way  to  8th  Marines.  The  expected  total  load  on  Relay  102  will  be  335.8  messages 
per  hour  (13/12  *310). 

1/8  produces  its  own  310  messages  per  hour  on  average.  It  is  also  the  target  of 
100%  of  all  three  subordinate  units’  traffic  (an  expected  additional  930  messages  per 
hour).  Add  to  this  the  310/12  messages  expected  to  arrive  from  8th  Marines  and  the  total 
expected  load  for  1/8  is  1 265.8  messages  per  hour.  This  is  over  3.7  times  the  load  on 
Relay  102. 

This  example  gives  some  insight  into  why  the  model  is  behaving  as  it  is.  The 
bandwidth  limiting  element  of  the  network  is  not  the  relay,  it  is  the  battalion 
headquarters. 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


This  thesis  set  out  to  examine  the  effects  of  changing  relay  suite  bandwidth  in  a 
JTRS  network.  A  discrete-event  simulation  model  was  developed  to  model  the  system 
and  was  implemented  in  Java  using  Simkit.  The  results  of  the  simulation  indicate  that  the 
JTRS  network  performance,  as  measured  by  timely  arrival  of  messages,  is  insensitive  to 
even  large  changes  in  relay  suite  bandwidth. 

The  simulation  model  produced  for  this  thesis  has  been  demonstrated  and  has 

( 

performed  correctly  in  those  cases  tested.  Correctly,  in  the  case  of  the  model’s 
performance,  means  only  that  the  model  functioned  as  designed,  not  that  it  was  a  perfect 
representation  of  the  as-yet-nonexistent  JTRS  communication  network.  This  thesis  has 
built  a  base  upon  which  further  improvements  can  be  built. 

Time  did  not  permit  the  author  to  make  all  of  the  enhancements  to  the  model  that 
had  originally  been  planned.  Several  key  areas  for  further  research  are  message  routing 
schemes,  different  abstractions  of  bandwidth  utilization,  and  implementation  of  terrain 
effects  modeling. 

Messages  are  currently  randomly  routed  to  a  member  of  the  sender’s  commList. 
The  only  firm  restriction  to  this  is  that  a  message  will  not  be  routed  back  to  the  entity  that 
sent  it  to  the  current  holder.  This  prevents  “ping-ponging”  of  messages  back  and  forth 
between  two  entities  in  communication  with  each  other  but  who  are  in  communication 
with  no  other  entities.  However,  messages  tend  to  spend  extra  time  in  the  system  due  to 
the  simplicity  of  the  routing  system.  A  smarter  implementation  might  be  to  poll  members 
of  the  commList  to  determine  if  any  of  them  have  the  messages  recipient  on  their  own 
commList.  In  this  case  the  message  would  be  sent  to  the  first  member  reporting 
communication  with  the  recipient.  Alternatively,  a  shortest  path  algorithm  could  be 
implemented  to  pick  the  best  feasible  route  from  sender  to  target. 

Bandwidth  utilization  in  this  model  is  purely  a  function  of  message  size.  The 
message  takes  up  a  portion  of  the  JTRS’s  bandwidth  proportional  to  its  size  and  keeps 
that  bandwidth  tied  up  for  a  time  also  proportional  to  the  message’s  size.  For  example,  a 
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message  of  size  .  1  (or  1 0%  of  a  JTRS  bandwidth),  will  take  1 0%  of  the  sender’s 
bandwidth  for .  1  minute,  likewise  as  message  of  size  .2  will  take  20%  for  .2  minutes.  No 
matter  whether  the  JTRS  has  100%  of  its  bandwidth  available  or  only  20%,  the  message 
takes  the  same  amount  of  time  to  transmit.  A  scheme  could  be  developed  to  treat 
bandwidth  in  a  way  that  reduces  the  time  spent  in  message  transmission  if  the  JTRS  has 
additional  bandwidth  available.  This  could  easily  be  accomplished  by  assigning  each 
message  a  weight  base  on  the  its  size  and  assigning  each  radio  a  maximum  weight 
capacity  per  time  period.  This  suggested  method  is  similar  to,  but  simpler  to  implement 
than,  the  packet  system  of  data  transmission,  in  which  every  message  is  broken  down  into 
like  sized  packets  that  are  then  individually  routed  to  the  target. 

A  last  major  enhancement  is  the  introduction  of  terrain  effects.  The  model 
currently  does  not  take  terrain  in  to  account  when  determining  the  commList.  Instead, 
the  cookie  cutter  approach  is  taken:  if  another  unit  is  with  the  user  selected  radio  range, 
then  that  unit  is  added  to  the  commList.  This  does  not  model  the  effects  of  terrain  on 
radio  wave  propagation,  which  can  and  do  cause  very  large  variations  from  nominal  radio 
ranges. 

The  single  major  recommendation  is  one  that  was  identified  early  in  the  research 
for  this  thesis.  This  recommendation  is  that  the  Marine  Corps  take  steps  to  capture  its 
actual  bandwidth  requirements  and  usage.  This  needs  to  be  done  in  order  to  properly 
apply  the  power  of  modeling  and  simulation  to  our  C4I  architecture,  and  to  ensure  we 
procure  C4I  systems  that  will  serve  our  needs  into  the  future.  Data  on  the  frequency  of 
occurrence  of  messages  and  the  size  of  those  messages  is  a  critical  first  step  in 
determining  what  the  C4I  architecture  of  the  future  needs  to  be  able  to  do. 

In  conclusion,  this  model  helped  to  gain  insight  into  a  JTRS  network  by  giving 
unexpected  and  counter-intuitive  results,  which  in  turn  caused  a  deeper  examination  of 
the  system  under  study.  Upon  further  examination,  these  results  make  sense  and  are  the 
valid  results  of  the  model,  rather  than  of  logical  or  syntactical  errors  in  the  programming. 
The  implication  of  the  results  of  this  thesis  is  that  the  battalion  headquarters  are  the 
bandwidth  bottlenecks  in  the  network.  It  is,  therefore,  at  the  battalion  level  that 
bandwidth  should  be  increased  in  order  to  improve  network  performance. 
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APPENDIX  A.  JAVA  CLASSES  DEVELOPED  FOR  THIS  THESIS 


1.  CommMover.  This  class  extends  the  BasicMover  of  Simkit.  Moves  a  JTRS  and  can 
report  which  particular  JTRS  it  is  associated  with. 

2.  CombatManager:  This  class  controls  the  changes  in  unit  speed  and  communication 
intensity  throughout  the  scenario. 

3.  CommLinkMediator:  Extends  the  CookieCutterMediator.  Modifies  the 
CookieCutterMediator  to  allow  sensors  to  have  a  reference  to  the  target,  instead  of  a 
surrogate.  This  removes  the  information  hiding  feature  of  the  CookieCutterMediator,  but 
allows  the  JTRS  to  keep  a  CommList. 

4.  JTRS:  This  class  is  the  heart  of  the  model.  Each  instance  creates  its  own 
ArrivalProcesses,  QueueManger,  Receiver,  and  Transmitter. 

5.  Message:  This  class  keeps  track  of  its  own  size,  transmission  time,  target,  sender,  and 
the  JTRS  that  most  recently  transmitted  it.  Messages  are  the  objects  passed  around  the 
network. 

6.  MessageComparator:  This  class  sorts  Messages  for  the  QueueManager,  ensuring 
that  Messages  are  put  in  the  proper  queue  position. 

7.  PenaltyCalc:  This  class  listens  to  all  Receivers  to  hear  Message  arrivals.  Tracks  the 
number  of  late  Messages  of  each  priority  and  returns  the  Penalty  Function  value  when 
asked. 

8.  QueueManager:  This  class  puts  Messages  on,  and  removes  Messages  from  the 
Queue.  Sends  Messages  to  the  receiver  when  bandwidth  is  available.  Receives 
generated  Messages  from  the  JTRS  and  received  Messages  from  the  Receiver. 

9.  Receiver:  This  class  listens  to  all  Transmitters  on  the  JTRS  commList  and  receives 
Messages  intended  for  its  JTRS. 

1 0.  TestScenario:  This  is  the  test  program  that  makes  that  sets  up  and  runs  the 
simulation  of  the  scenario. 

1 1 .  Transmitter:  This  class  is  responsible  for  picking  a  member  of  the  commList  and 
then  sending  the  Message  to  that  member.  Receives  Messages  for  transmission  from  the 
QueueManager. 


53 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


54 


LIST  OF  REFERENCES 


1.  United  States  Marine  Corps,  Marine  Corps  Doctrinal  Publication  1,  Warfighting, 
United  States  Marine  Corps,  1997. 

2.  United  States  Marine  Corps,  Marine  Corps  Concept  Paper,  Operational  Maneuver 
from  the  Sea ,  United  States  Marine  Corps,  1 996. 

3.  United  States  Marine  Corps,  Marine  Corps  Concept  Paper,  Ship-to-Objective 
Maneuver,  United  States  Marine  Corps,  1 997. 

4.  Department  of  Defense,  Joint  Tactical  Radio  System  Operational  Requirements 
Document,  1998. 

5.  Tanir,  Oryal,  Modeling  Complex  Computer  and  Communication  Systems,  McGraw- 

Hill,  1997. 

6.  Marine  Corp  Combat  Development  Command,  brief  on  Operational  Maneuver  form 
the  Sea,  No  date. 

7.  Marine  Corps  Combat  Development  Command,  Concepts  Developments  Division 
brief  entitled.  Warfighting  Concept  for  the  21st  Century,  available  at 
www.concepts.quantico.usmc.mil.  No  date. 

8.  Joint  Tactical  Radio  System  Joint  Program  Office  website:  www.jtrs.sarda.army.mil. 
No  date. 

9.  Department  of  Defense,  Joint  Tactical  Radio  System  Mission  Needs  Statement,  1 997. 


55 


10.  C4ISR  Architecture  Branch,  Requirements  Division,  Marine  Corps  Combat 
Development  Command,  Overview  of  Proposed  2010  C4ISR  Architecture  for  the 
Marine  Corps.  No  date. 

1 1 .  Marine  Corps  Combat  Development  Command  brief  USMC  MCCDC  Proposal  to 
JTRS  JPO:  USMC  OMFTS/Regimental  Landing  Team  Mid-Level  Fidelity  Simulation 
Scenario.  No  date. 

12.  Raytheon,  USMC  Communications  Architecture  Study:  Final  Report,  No  date. 

13.  Law,  Averill  and  Kelton,  W.David,  Simulation  Modeling  &  Analysis,  McGraw-Hill, 
1991. 

14.  Schruben,  Lee  Simulation  Modeling  with  Event  Graphs,  Communications  of  the 
ACM,  26,  957-963,  1983. 

15.  Buss,  Arnold,  Introduction  to  Event  Graphs,  OA3302  Class  Handout,  1998. 

16.  Stork  Kirk,  Sensors  in  Object  Oriented  Discrete-Event  Simulation,  Master’s  Thesis, 
Naval  Postgraduate  School,  1996. 

17.  Conover,  W.  J.,  Practical  Nonpar ametric  Statistics,  3rd  Edition,  New  York,  1999. 


56 


INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Technical  Information  Center . (2) 

8725  John  J.  Kingman  Rd,  STE  0944 

Ft  Bel  voir,  VA  22060-6218 

2.  Dudley  Knox  Library . (2) 

Naval  Postgraduate  School 

411  Dyer  Rd 

Monterey,  CA  93943-5101 

3.  Director,  Training  and  Education . (1) 

MCCDC,  Code  C46 

1019  Elliot  Road 
Quantico,  VA  22134-5027 

4.  Director,  Marine  Corps  Research  Center . (2) 

MCCDC,  Code  C40RC 

2040  Broadway  Street 
Quantico,  VA  22134-5107 

5.  Director,  Studies  and  Analysis  Divsion . (1) 

MCCDC  Code  C45 

300  Russell  Road 
Quantico,  VA  22134-5130 


57 


Marine  Corps  Representative . 

Naval  Postgraduate  School 

Code  037,  Bldg.  330,  Ingersoll  Hall,  Room  116 

555  Dyer  Road 

Monterey,  CA  93943 

Marine  Corps  Tactical  Systems  Support  Activity 
Technical  Advisory  Branch 
Attn:  Librarian 
Box  555171 

Camp  Pendleton,  CA  92055-5080 

Professor  Arnold  H.  Buss . 

Code  OR/Bu 

Operations  Research  Department 
U  S.  Naval  Postgraduate  School 
Monterey,  CA  93943 

Professor  William  G.  Kemple . 

Code  CC/Ke 

Operations  Research  Department 
U.S.  Naval  Postgraduate  School 
Monterey,  CA  93943 

Major  Thomas  E.  Turner,  USMC . 

RR  2,  Box  20 

Hollis  Center,  ME  04042 


